Для чего нужен refresh token
Что проверяют
Понимаете ли вы, зачем токенов два и какие сценарии за этим стоят. Аналитику следом обычно дают задачу: описать, что происходит, когда токен истёк, пользователь вышел или токен украли.
Как отвечать
В OAuth 2.0 и OpenID Connect пара устроена так:
- access token: живёт недолго, обычно от 5 до 60 минут, и уходит с каждым запросом к API. Часто это JWT, который сервис проверяет по подписи, не обращаясь к серверу авторизации, поэтому отозвать его до истечения срока сложно;
- refresh token: живёт дни или недели, отправляется только на сервер авторизации (
grant_type=refresh_token) и хранится у него, поэтому его можно отозвать.
Смысл схемы в балансе. Короткий access token ограничивает ущерб от утечки. Refresh token избавляет от повторного входа каждые 15 минут и даёт системе точку контроля: выход, блокировка учётной записи или смена пароля отзывают его, и новые access token больше не выдаются.
Сильный ответ добавляет ротацию: при каждом обновлении выдаётся новый refresh token, а старый гасится. Если старый предъявили повторно, это признак кражи, и сервер отзывает всю цепочку. Для браузерных и мобильных клиентов RFC 9700 требует ротации или привязки токена к клиенту.
В требованиях аналитик фиксирует сроки жизни, абсолютный предел сессии, место хранения (в браузере cookie с HttpOnly и Secure, не localStorage) и сценарий: API вернул 401, клиент обновил токен и повторил запрос, при неудаче отправил на вход.
Где спотыкаются
Думают, что refresh token идёт с каждым запросом к API. Тогда он теряет смысл: риск утечки у него становится таким же, как у access token.
Не описывают параллельные запросы. Если пять запросов одновременно получили 401 и каждый пошёл обновлять токен, при ротации четыре предъявят уже погашенный токен и выкинут пользователя.
Считают выходом из системы удаление токенов на клиенте. Без отзыва refresh token на сервере сессия продолжает жить.