Access и Refresh токены

Пара токенов — стандартный подход в JWT-аутентификации, разделяющий короткоживущий токен доступа и долгоживущий токен обновления.

Access token

• Короткий срок жизни (обычно 5–15 минут)
• Содержит claims: subject (логин), roles, дополнительные данные (firstName и т.д.)
• Передаётся в заголовке Authorization: Bearer <token>
• Используется для доступа к защищённым эндпоинтам

Refresh token

• Длительный срок жизни (обычно 30 дней)
• Содержит минимум данных — только subject
• Хранится на клиенте, отправляется только на эндпоинт обновления токенов
• Позволяет получить новый access token без повторного ввода пароля

Зачем два разных ключа

Для access и refresh токенов используются разные секретные ключи. Это даёт:

• Изоляция сервисов — микросервисы, валидирующие access token, не имеют доступа к ключу refresh token
• Безопасная ротация — при компрометации сервиса можно заменить только ключ access token без разлогинивания всех пользователей
• Разделение ответственности — сервер аутентификации работает с обоими ключами, остальные сервисы — только с access-ключом

Жизненный цикл

1. Клиент отправляет логин и пароль → получает пару токенов
2. Access token используется для запросов к API
3. Через 5 минут access token протухает → клиент отправляет refresh token на /auth/token → получает новый access token
4. На 25–29 день клиент обновляет всю пару через /auth/refresh

Хранение refresh токенов на сервере

Сохранение refresh token на сервере (в HashMap, Redis или БД) повышает безопасность:

• Злоумышленник не может создать валидный токен, даже зная секретный ключ, без знания точного времени создания
• Позволяет отзывать токены — удаление из хранилища блокирует генерацию новых access token
• Защита от повторного использования — после обновления пары старый refresh token становится невалидным

См. также

• Отзыв JWT токенов — blacklist и мультидевайс logout
• JWT как механизм сессий — почему JWT не подходит для замены серверных сессий