В качестве сессионных секретов?

https://codex.so/jwt

Более привычное решение — сопоставление пользователя некому уникальному идентификатору — токену. При первом логине клиенту от сервера выдается токен, образованный хеш-функцией от каких-нибудь уникальных данных пользователя (id, логин, пароль). В базу заносится пара токен — id. При следующих запросах клиент передает этот токен, а сервер ищет в базе запись. Если запись найдена, пользователя авторизуют.

Более привычное решение — сопоставление пользователя некому уникальному идентификатору — токену. При первом логине клиенту от сервера выдается токен, образованный хеш-функцией от каких-нибудь уникальных данных пользователя (id, логин, пароль). В базу заносится пара токен — id. При следующих запросах клиент передает этот токен, а сервер ищет в базе запись. Если запись найдена, пользователя авторизуют.

Это как ты предполагаешь использовать jwt, или ты процитировал описание своего текущего подхода к работе с сессионными токенами, от которого хочешь уйти?

это ответ на вопрос про сессионные секреты. чтобы не манипулировать названиями и аббривеатурами я привел статью с описанием.

Но если у тебя сейчас сессионныные токены в общей для обоих томкатов базе, то почему они не принимаются другим из них при падении одного?

потому что сейчас нет токенов, сейчас сессии, которые работают вот так

И, как бы, если ты хочешь юзать jwt на сайтах, то эти токены у тебя тоже будут сессионными.

мне кажется, тут проблема в том, что ты привязываешься к словам

Друзья, напоминаем,  5  декабря, в 19:00 начнется трансляция встречи DevOps : New Year is coming.  

Ссылка на трансляцию:
https://www.youtube.com/watch?v=CVYwjqFX8XI

Для вас докладывают:
Александр Бугаев (Газпром нефть) - Корпоративный OpenShift (Security Design&Architecture).
- предпосылки внедрения OSCP в ГПН
- корпоративные требования ИБ для платформы контейнеризации
- процессы и инструменты DevSecOps

И Александр Чистяков - «Базы данных в Kubernetes: проблемы развёртывания и эксплуатации»

абстрагируйся, смотри на технологию, а не на то, как она называется

Я и абстрагируюсь. Просто, если мы говорим про веб, и при этом не хочется хранить токены на стороне бэкенда, а вместо этого сделать client-side сессии, валидируемые криптографически, то это далеко не всегда упрощает жизнь. Например, встает проблема инвалидации сессий.

При этом, обмен юзерского логопасса на такой токен - тоже не всегда тривиальная процедура. Людям приходится выдумывать монстров, вроде oauth, для того, чтобы решать эту задачу.

та приблуда на фласке oauth и есть

flask-login-то? Он про oauth ничего не знает.

Почему не получилось?

Что за проблемы были?

некоторые кастомные проверки, например проверки существования бекапов. Прометей все-таки не для этого сделан (хотя это и можно сделать через textcollector)

и тебе админы могут высказать претензии, что нельзя в прометее удобно посмотеть список хостов и ассоциированные с ним метрики/проверки

Угум. Да он местами не удобен. Уже высказали)