(имейте ввиду, я допускаю, что я неправ)

Кстати, а есть какая-то литература или какой-то сайт-учебник или еще чё по написанию обобщенному бекенда? А то все знают, что такое DAO, Middleware и подобные хрени, а я не знаю. Чисто теоретически, в такой книге и инфа по безопасности будет приложена.

Имхо идентификация пользователя и изменение его права вообще несильно взаимосвязанные задачи в части менят изменят права.
По нормальному перед каждой значимой операцией должны определяться права пользователя.
Если у пользователя есть некое право и он представил корректные данные выполняешь операцию.
Если у пользователя нет права, генерируешь ошибку.
А какая фиг разница какая id сессии.

Винда кстати права в системе применяет при входе и тыщу раз было так что после изменений прав пользователя ему нужно было выйти-зайти 🤷🏻

Вы походу не в теме))

JWT - это такая штука, которая превращает JSON в Base64, и еще подписывает. То есть чувак присылает JWT, библиотека десериализует его, проверяет подпись (доказывает, что json создан сервером). Еще в JWT можно впихнуть время жизни, и по его истечению библиотека десериализации автоматически признает токен недействительным.

Технологию сделали чтобы пересылать сообщения между микросервисами в интернете. И зачем-то юзают как проверку сессии.

Но.
Дату обнулить удалённо конечно-же нельзя, но если её хранить в БД, то незачем хранить внутри токена.
Сам токен обнулить тоже нельзя, потому что его тогда придется хранить в БД, что обесценивает собственные механизмы безопасности в JWT.
Да и какую-то важную инфу там хранить... непонятно зачем. Если токеном найти юзера в БД, то и всю остальную инфу оттуда же можно вытащить.

Это моя позиция.

Не хочу выглядеть тем, кто всё освещает выгодно для себя, но каких-то логичных аргументов в пользу я не слышал.

Так, а почему jwt не хранят в бд ? Просто или все бэк энд разрабы на моих проектах троли, или они чего-то не понимают.

Про сам jwt да не в курсе.
Но я нигде и не писал о нем )
Я лишь  выразил свою мысль что вот есть токен и нужно определить некие права или урезать их. И два механизма получения идентификатора и определение его прав мало взаимосвязаны. Потому что токен это лишь механизм связать некого пользователя и есть механизм определения прав. Но права определяются по пользователю, а не по сессии.
Если предположить что есть 2 системы.
Одна выдала токен другой системе.
И сохранила у себя инфо что вот дала токен и связала его с неким "пользователем".
Если вдруг у пользователя поменяется набор прав, как одно другому мешает выполнить некий запрос того пользователя кто представил токен или отклонить этот запрос.

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

Прикладные это?

Условно те что в унике дают?

Условно. Дейкстры, поиска по дереву и т.д.

А зачем его хранить в БД? У него все механизмы специально сделаны так, что безопасны без всяких проверок и сравнений с данными в БД. Но безопасны по своему.

Вот JWT можно распарсить и достать из него имя юзера. Зачем тогда JWT в БД сохранять? Какая в этом польза?

А реальные конкретные данные пользователя типа имени пользователя, постов, комменариев превращать в JWT и сохранять в БД это вообще безумие (но я уверен, вы не это имели ввиду).

Вообще, если смотреть на токен JWT как на команду из одного верифицированного сервиса в другой, всё довольно логично и изящно. Кто попало токен создать не может, живёт токен недолго, в базе данных команду из точки А в точку Б хранить не надо и остальные фичи ЖВТ.
А как ID сессии его зачем использовать? Почему не просто набор рандомных знаков?
Может, типа подписано? Так если кто-то способен перебором узнать id сессии (не способен), то и токен жвт он тем же перебором разгадает, и подпись не спасёт.

Вообще, генерация жвт это не какая-то магия, она довольно проста.

function getJwt(header, data, secretKey) {
   let body = base64(JSON.stringify(header)) + '.' + base64(JSON.stringify(data));
   return body + '.' + hash(body, secretKey);
}

(Примерно такой код был в официальных доках жвт).
То есть безопасность - это не какая-то магия. Это просто данные + хеш от (данные + соль). Подменишь данные, и хеш не совпадёт, а без соли хеш не пересоздать.

Но зачем это нужно и так неподделываемому айди сессии?
Айди могут украсть, скажете вы. И токен жвт тоже могут украсть, целиком, и с данными, и с подписью.

Может, я просто чего-то в современных сессиях не понимаю? Просто все фичи ЖВТ в вопросе сессий выглядят как пятое колесо. Непонятно, зачем они, что с ними делать и какую проблему они решают.


Блин, чёто я повторяюсь...

Ну, я только с обходами графа встречался

У знакомого роутинг был какой-то извращенный через поиск в дереве

Больше не припомню

А* юзаем, но уже готовый, сами не писали

Ну и Стейтмашины, но это скорее к структурам

В бд могут сохранять, чтобы было удобно те или иные данные с ним связать? 🤷🏻

Думаю что ты во многом прав, но факт остаётся фактом, jwt используется как просто идентификатор, при помощи которого вытягивается пользователь из базы, т.к. современные, боль мень большие приложухи требуют куда больше инфы о пользователе, чем хранится в сессии или зашифровано в токене... Так что в любом раскладе тянется объект из бд. А, ну ещё и редис ставить не надо )

Все

Из опыта

Ну т.е. пользователь связывается с токеном

Вот об этом я и писал в самом начале...