Два токена существуют, чтобы разрешить прямой конфликт: access-токен должен отправляться при каждом запросе (поэтому он сильно раскрыт), но при этом вы хотите сессии, которые длятся долго без принуждения к частым входам. Нельзя безопасно иметь и то, и другое в одном токене — поэтому вы разделяете задачу.
Authorization при каждом вызове API. Поскольку он передаётся постоянно, утечка вероятна; сохранение его коротким означает, что украденный истекает почти немедленно.Login ──▶ access (15m) + refresh (30d)
Каждый вызов API ──▶ отправить access
Access истёк ──▶ отправить refresh ──▶ новый access (+ ротированный refresh)
| Один долгоживущий access-токен | Access + refresh | |
|---|---|---|
| Раскрытие | Отправляется при каждом запросе, живёт долго → большое окно кражи | Access короткоживущий; refresh отправляется редко |
| Отзыв | Трудно (stateless JWT нельзя «отвыпустить») | Отзовите refresh-токен; access умирает в течение минут |
| UX | Частый повторный вход, если короткий | Остаётся в системе без повторного ввода учётных данных |
| Радиус поражения при утечке | Большой | Малый (access быстро истекает) |
httpOnly, вне досягаемости XSS.Это стандартный современный дизайн аутентификации, и интервьюеры спрашивают об этом, чтобы увидеть, понимаете ли вы почему, а не только как. Ключевое понимание — это компромисс: statelessness и короткое раскрытие (access) против долгих сессий и возможности отзыва (refresh). Ошибиться — долгоживущий access-токен, без ротации, refresh, хранящийся в localStorage — превращает единственный утёкший токен в долгосрочную компрометацию аккаунта. Назвать разделение и то, что даёт каждый токен, — это то, что ожидается от инженера, осознающего безопасность.
Библиотека вопросов для IT-собеседований с подробными ответами — от Junior до Senior.
Поддержать