Access-токен проверяется на каждом защищённом запросе; refresh — только на endpoint обновления и по серверному состоянию сессии. Для немедленного отзыва JWT нужен stateful-механизм, не одна подпись.
Как на бэкенде правильно организовать работу с JWT-токенами? Где и как должны проверяться Access и Refresh токены, как обеспечить их безопасное хранение и что делать, если токен пользователя нужно отозвать из-за компрометации до истечения его срока действия?
Access-токен проверяется на каждом защищённом запросе; refresh — только на endpoint обновления и по серверному состоянию сессии. Для немедленного отзыва JWT нужен stateful-механизм, не одна подпись.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Access-токен проверяется на каждом защищённом запросе; refresh — только на endpoint обновления и по серверному состоянию сессии. Для немедленного отзыва JWT нужен stateful-механизм, не одна подпись.
Проверяйте разрешённый алгоритм, подпись, issuer, audience, срок и назначение токена. Access делайте короткоживущим; refresh храните защищённо, ротируйте и обнаруживайте повторное использование. На сервере можно хранить хеш refresh и статус семейства сессии. Для досрочного отзыва access — denylist по jti или версия/статус сессии с проверкой. В браузере HttpOnly Secure cookie требует защиты CSRF; desktop использует защищённое хранилище ОС. Не логируйте токены и не считайте JWT зашифрованным по умолчанию.
Источник: cheatsheetseries.owasp.org.