Перейти на PRO

Что такое refresh token в механизме JWT?

Тип вопроса: Тестирование безопасности Вероятность: 10% Категория: QA Тестировщик

Ответ

Refresh token — это долгоживущий токен, используемый для безопасного получения новых access token без повторного ввода учетных данных пользователя. Это ключевой компонент для баланса между безопасностью и удобством в OAuth 2.0 и JWT-аутентификации.

Принцип работы:

  1. Первичная аутентификация: Пользователь входит с логином/паролем.
  2. Выдача пары токенов: Сервер аутентификации возвращает: 
    {
  "access_token": "eyJhbGciOiJIUzI1NiIs...",
  "refresh_token": "dGhpcyBpcyBhIHNlY3JldCByZWZyZXNoIHRva2Vu",
  "expires_in": 900 // Access token живёт 15 минут
}
  3. Использование access token: Клиент использует его для доступа к API. Он короткоживущий (минуты/часы).
  4. Обновление по истечении срока: Когда access_token протухает, клиент отправляет refresh_token на специальный endpoint (например, POST /auth/refresh).
  5. Выдача новой пары: Сервер проверяет refresh_token и выдает новую пару access_token и refresh_token.

Почему это безопасно?

  • Минимизация риска: Короткая жизнь access_token снижает ущерб в случае его утечки.
  • Контроль доступа: Refresh_token можно отозвать на сервере (добавив в blacklist), немедленно прекратив доступ пользователя.
  • Безопасное хранение: Refresh_token должен храниться максимально безопасно (например, в HttpOnly, Secure, SameSite cookie), чтобы быть недоступным для JavaScript (защита от XSS).

Ответ 18+ 🔞

Давай разберём эту тему, а то у некоторых в голове про токены — как у того Герасима с Муму, только «му-му» и получается.

Вот представь: ты зашёл в приложение. Ввёл логин-пароль, и тебе выдали два ключа. Первый — access_token. Это как пропуск на закрытую вечеринку, но действует он, блядь, минут пятнадцать. Ты походил, выпил, пообщался — и всё, охрана тебя выставляет. Но у тебя же есть второй ключ — refresh_token. Это уже не пропуск, а, сука, доверенная бумажка от самого организатора. С ней ты подходишь к стойке, говоришь: «Слушай, мой пропуск протух, а я ещё не всё успел». Тебе смотрят на эту бумажку, кивают и выдают НОВЫЙ пропуск и, внимание, НОВУЮ такую же бумажку. Старую забирают. Вот и вся магия.

А теперь, почему это не просто удобно, а ещё и, блядь, безопасно? Да потому что если твой короткий пропуск (access_token) кто-то украдёт или подсмотрит — у вора будет всего 15 минут, чтобы натворить дел. А твоя «доверенная бумажка» (refresh_token) лежит не в кармане, а в сейфе. В мире веба этот сейф — это HttpOnly, Secure, SameSite куки. JavaScript до них не доберётся, хоть обосрись. XSS-атаки отдыхают.

И главный козырь: если что-то пошло не так, или ты сам захотел всё прекратить, администратор (сервер) может взять и, блядь, аннулировать твою «доверенную бумажку», добавив её в чёрный список. И всё, нахуй! Новых пропусков ты больше не получишь. Пока не придёшь заново и не докажешь, что ты — это ты.

{
  "access_token": "eyJhbGciOiJIUzI1NiIs...",
  "refresh_token": "dGhpcyBpcyBhIHNlY3JldCByZWZyZXNoIHRva2Vu",
  "expires_in": 900
}

Вот смотри на этот JSON. expires_in: 900 — это и есть те самые 15 минут жизни основного токена. Как только время вышло, клиент не паникует, а спокойно шлёт старый refresh_token на специальный маршрут, типа POST /auth/refresh. Сервер, если токен валидный и не в бане, выдаёт свежую парочку. И так по кругу, пока пользователь активен. А если refresh_token вдруг скомпрометирован — его можно отозвать одним движением, и весь цикл, ёпта, накрылся медным тазом. Красота же!

© ХакСобесов, 2026
support@hacksobesov.com