Refresh token — механизм обновления токенов доступа¶

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

¶Назначение и место в протоколах

В OAuth 2.0 access token, как правило, живёт недолго — от минут до часов. Это сделано намеренно: короткоживущий токен ограничивает ущерб от его кражи. Но короткий срок жизни создаёт проблему — клиентское приложение вынуждено часто обращаться к серверу аутентификации за новым токеном, что неудобно и нагружает сеть.

Refresh token решает эту задачу. Сервер выдаёт его вместе с первым access token (в ответе на grant-запрос, например Authorization Code Grant). Когда access token истекает, клиент отправляет запрос на эндпоинт обновления (обычно /oauth/token) с grant_type=refresh_token и получает новый access token, а часто и новый refresh token. Пользователь при этом не вводит пароль повторно.

В OpenID Connect refresh token является частью ответа на запрос ID token и access token и позволяет приложению получать новые токены доступа и, при необходимости, обновлять ID token.

¶Хранение на стороне клиента

Refresh token — это секрет, и его хранение — центральный вопрос безопасности. В веб-приложениях его нельзя хранить в localStorage или sessionStorage браузера: любой XSS-вектор позволяет злоумышленнику извлечь токен. Рекомендуемые практики:

• HttpOnly Secure cookie — токен хранится в cookie, недоступной для JavaScript, с флагами Secure и SameSite.
• Backend-for-frontend (BFF) — токен хранится на сервере приложения, браузер получает только сессионную cookie.
• Мобильные приложения — на iOS используется Keychain, на Android — Keystore; в обоих случаях токен шифруется и привязывается к устройству.

В нативных приложениях refresh token часто хранится в защищённом хранилище, но физическая защита устройства остаётся слабым местом.

¶Ротация и отзыв

Современные рекомендации (RFC 9700, бывший OAuth 2.0 Security Best Current Practice) предписывают использовать ротацию refresh token: при каждом обновлении сервер выдаёт новый refresh token, а предыдущий инвалидирует. Это ограничивает окно эксплуатации украденного токена.

Для обнаружения кражи применяется детектор повторного использования (refresh token reuse detection). Если сервер получает запрос с уже отозванным refresh token, он делает вывод о компрометации и отзывает всю цепочку токенов, выданных в рамках этого grant. Пользователь при этом вынужден пройти аутентификацию заново.

¶Сроки жизни

Типичные значения:

Для систем с повышенными требованиями (банки, госуслуги) применяются короткие refresh token с обязательной ротацией и привязкой к устройству.

¶Связь с другими механизмами

Refresh token не следует путать с session cookie: cookie — это механизм транспорта сессии на уровне HTTP, а refresh token — объект авторизации, который может передаваться разными способами. Также refresh token отличается от PKCE (Proof Key for Code Exchange) — PKCE защищает код авторизации при обмене на токены, а refresh token обеспечивает длительный доступ без повторной аутентификации. В OAuth 2.1 PKCE обязателен для всех клиентов, а refresh token должен быть конфиденциальным (public clients получают его только с ротацией и привязкой к PKCE).

¶Применение

Refresh token активно используется в корпоративных интеграциях (доступ к API без участия пользователя), в мобильных приложениях, в Single Sign-On системах. В России механизмы OAuth 2.0 и refresh token применяются в Госуслугах, в API крупных платёжных и телекоммуникационных компаний, а также в отраслевых интеграционных шинах.

Источники:

• RFC 6749 — The OAuth 2.0 Authorization Framework
• RFC 9700 — OAuth 2.0 Security Best Current Practice
• OpenID Connect Core 1.0
• OWASP OAuth Cheat Sheet