LINUX.ORG.RU

История изменений

Исправление OxiD, (текущая версия) :

JWT так же используется в микросервисной архитектуре, когда есть отдельный микросервис для авторизации, и только он может «вытаскивать из БД сессию по ключу и проверять». Остальные доступа к этой бд вообще не имеют (а часто могут вообще не иметь доступа к списку юзеров, за ненадобностью) и могут только проверить что токен еще валидный, соотвественно использовать данные из него.

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

Я делал примерно так - в токене хранил поле с хешем важных данных о юзере (права доступа, дата смены пароля, сколько раз просил разлогинить со всех устройств итд). Когда access-token протухает - проверяем хеш в рефреш токене, и если что-то поменялось то рефреш токен невалиден - пользователь разлогинен.

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

Но если токен живет минуту-две, то это скорее всего не критично (юзер может несколько часов узнавать что у него учетку угнали, и пара минут тут роли не сыграют).

Исправление OxiD, :

JWT так же используется в микросервисной архитектуре, когда есть отдельный микросервис для авторизации, и только он может «вытаскивать из БД сессию по ключу и проверять». Остальные доступа к этой бд вообще не имеют (а часто могут вообще не иметь доступа к списку юзеров, за ненадобностью) и могут только проверить что токен еще валидный, соотвественно использовать данные из него.

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

Я делал примерно так - в токене хранил поле с хешем важных данных о юзере (права доступа, дата смены пароля, сколько раз просил разлогинить со всех устройств итд). Когда access-token протухает - проверяем хеш в рефреш токене, и если что-то поменялось то рефреш токен невалиден - пользователь разлогинен.

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

Но если токен живет минуту-две, то это скорее всего не критично (юзер может несколько часов узнавать что у него учетку угнали, и пара минут тут роли не сыграют).

Исходная версия OxiD, :

JWT так же используется в микросервисной архитектуре, когда есть отдельный микросервис для авторизации, и только он может «вытаскивать из БД сессию по ключу и проверять». Остальные доступа к этой бд вообще не имеют (а часто могут вообще не иметь доступа к списку юзеров, за ненадобностью) и могут только проверить что токен еще валидный, соотвественно использовать данные из него.

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

Я делал примерно так - в токене хранил поле с хешем важных данных о юзере (права доступа, дата смены пароля, сколько раз просил разлогинить со всех устройств итд). Когда access-token протухает - проверяем хеш в рефреш токене, и если что-то поменялось то рефреш токен невалиден - пользователь разлогинен.

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