Комментарии 5
Детектор ИИ зашкаливает. Ровно как и на других статьях автора.
К слову, статья довольно информативная и полезная на практике. Жаль, что её писал не человек, а ИИ. Я и сам в любой момент могу спросить у своего ИИ насчёт JWT и всех вышеперечисленных пунктов, если потребуется.
Нейротекст очень плохого качества.
До JWT большинство веб-приложений использовали серверные сессии
Они и сейчас используются между браузером и backend-ом, JWT тут ничего не поменял, аутентификация производится на этапе установления сессии, далее на сессию ссылаются по идентификатору.
Примеры Spring-кода тоже не особо помогают. С одной стороны, они недостаточно технически детальные: объектом какого класса является jwtService, как он заинжектился - непонятно. С другой стороны, эти примеры нафиг не нужны, никто не работает с jwt напрямую, spring security сам всё делает.
Для монолита вполне себе можно использовать jwt, да и мгновенно никто не запрещает отзывать токены.
Схема простая: refresh хранится в базе, и он по базе и проверяется. Хотим отозвать - помечаем как блок и refresh перестает работать. Если использовать чисто этот сценарий, то сессия потухнет в период времени до 10 - 15 минут.
Для отзыва access токена можно идти немного по другому пути, без бд, например, (это только пример а не истинна в последней инстанции) можно сделать список заблокированных access токенов, допустим через переменную окружения или типа того. Да даже через текстовый файл, это неважно. И сверять каждый раз все входящие access токены с этим списком, до тех пор, пока токен не протухнет. То бишь, ввести проверку на 10 - 15 минут. Учитывая что refresh уже заблокирован, access обновление не получит.
Типа того.
НО ВОТ БОЛЕЕ ПРАВИЛЬНЫЙ ВАРИАНТ:
Имеем два сикрета, на каждый токен,
В базе так же держим refresh и его обновление.
Меняем сикрет у access,
Абсолютно у всех пользователей протухнет access, они "пойдут" его менять, и у того кто имеет заблокированный refresh тот ничего не получит.
Вот и все.

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