JWT: как работает, зачем нужен и когда лучше не использовать

[dtkdtk]

Детектор ИИ зашкаливает. Ровно как и на других статьях автора.

К слову, статья довольно информативная и полезная на практике. Жаль, что её писал не человек, а ИИ. Я и сам в любой момент могу спросить у своего ИИ насчёт JWT и всех вышеперечисленных пунктов, если потребуется.

[kmatveev]

Нейротекст очень плохого качества.

До JWT большинство веб-приложений использовали серверные сессии

Они и сейчас используются между браузером и backend-ом, JWT тут ничего не поменял, аутентификация производится на этапе установления сессии, далее на сессию ссылаются по идентификатору.

Примеры Spring-кода тоже не особо помогают. С одной стороны, они недостаточно технически детальные: объектом какого класса является jwtService, как он заинжектился - непонятно. С другой стороны, эти примеры нафиг не нужны, никто не работает с jwt напрямую, spring security сам всё делает.

[rootCore]

Для монолита вполне себе можно использовать jwt, да и мгновенно никто не запрещает отзывать токены.

Схема простая: refresh хранится в базе, и он по базе и проверяется. Хотим отозвать - помечаем как блок и refresh перестает работать. Если использовать чисто этот сценарий, то сессия потухнет в период времени до 10 - 15 минут.

Для отзыва access токена можно идти немного по другому пути, без бд, например, (это только пример а не истинна в последней инстанции) можно сделать список заблокированных access токенов, допустим через переменную окружения или типа того. Да даже через текстовый файл, это неважно. И сверять каждый раз все входящие access токены с этим списком, до тех пор, пока токен не протухнет. То бишь, ввести проверку на 10 - 15 минут. Учитывая что refresh уже заблокирован, access обновление не получит.

Типа того.

НО ВОТ БОЛЕЕ ПРАВИЛЬНЫЙ ВАРИАНТ:

Имеем два сикрета, на каждый токен,

В базе так же держим refresh и его обновление.

Меняем сикрет у access,

Абсолютно у всех пользователей протухнет access, они "пойдут" его менять, и у того кто имеет заблокированный refresh тот ничего не получит.

Вот и все.

[asyncbtd]

А ловко вы с сикретами придумали

[rootCore]

Тут ещё такой момент что врят ли нужно будет в каком то приложении "моментально" отбирать права, это в основном только банкам и надо, но и у них - тоже самое с сикретами,

[pay2joy2]

Трюк прикольный.

Из неприятного - сразу всем рубить секрет когда надо заблокировать одного пользователя - жестковато. А если микросервисов много, этот секрет надо ещё по сервисам передать, и не дай бог надо переподнимать поды.

[rootCore]

это я так, образно написал, вариантов, на самом деле масса, плюс, я бы расценивал его как крайний, в случае какого нибудь форс - мажора, когда нужно очень резко отобрать права. а так, вот допустим, можно еще сделать временную проверку всех пользователей на блокировку аккаунта, до тех пор пока access не протухнет, по сути, такая нагрузка будет длиться в течение 10 минут.
по миркосервисам - тут зависит больше от изначальной организации их работы, можно сразу учитывать жесткие действия, такие как замена ключа. Например..... (тут нажно подумать) ну например могу прикинуть что если есть такая необходимость, то можно в очереди, в каждом запросе передавать токен и проверять его валидность, тогда если в очереди есть много запросов, и ключ сменили, и токен висел в очереди а потом пришел, на какой то сервис, и по скольку токен уже не валиден то и запрос будет отклонен.
ну как то так,
но, к слову, если это банковское приложение, можно организовать жизненный цикл токена не 10 минут, а, например, 30 секунд. этого же никто не запрещает, к слову, как конкретно в банке организовано я не особо в курсе, но думаю что подобным образом,