Refresh-токен¶

Refresh-токен — это криптографический токен, используемый в протоколах аутентификации и авторизации для получения нового access-токена (токена доступа) без необходимости повторного ввода учётных данных пользователем. Refresh-токены являются частью механизма, который позволяет балансировать между безопасностью и удобством использования веб-приложений, мобильных приложений и API.

¶Назначение и принцип работы

Основная цель refresh-токена — продление сессии пользователя или приложения без повторной аутентификации. В типичной схеме OAuth 2.0 и OpenID Connect, после успешной аутентификации сервер выдаёт два токена: access-токен (короткоживущий, обычно от 15 минут до 1 часа) и refresh-токен (долгоживущий, может действовать дни, недели или месяцы). Access-токен используется для доступа к защищённым ресурсам (например, к API), а refresh-токен — для получения нового access-токена, когда старый истекает.

Процесс обновления выглядит следующим образом:

1. Клиент (например, браузер или мобильное приложение) отправляет запрос к защищённому ресурсу, используя access-токен.
2. Сервер возвращает ошибку 401 (Unauthorized) с указанием, что токен истёк.
3. Клиент отправляет refresh-токен на специальный endpoint сервера авторизации (например, /token с параметром grant_type=refresh_token).
4. Сервер проверяет refresh-токен (его валидность, срок действия, принадлежность клиенту) и, в случае успеха, выдаёт новый access-токен (и, опционально, новый refresh-токен).
5. Клиент повторяет исходный запрос с новым access-токеном.

¶Отличия от access-токена

Refresh-токен и access-токен имеют разные характеристики и цели:

¶Типы refresh-токенов

Существует несколько подходов к реализации refresh-токенов:

¶1. Непрозрачные (opaque) токены

Случайная строка символов, которая хранится на сервере в базе данных вместе с метаданными (срок действия, идентификатор клиента, права доступа). При запросе на обновление сервер ищет токен в БД и проверяет его. Этот подход требует обращения к хранилищу при каждом обновлении, но обеспечивает возможность отзыва токена.

¶2. JWT-токены (JSON Web Token)

Самодостаточный токен, содержащий в своей полезной нагрузке (payload) информацию о пользователе, сроке действия, идентификаторе клиента и другие данные. JWT подписывается сервером, что позволяет проверять его целостность без обращения к БД. Однако отзыв такого токена сложнее — требуется вести список отозванных токенов (blacklist) или использовать короткий срок жизни.

¶3. Токены с ротацией (rotation)

При каждом обновлении сервер выдаёт новый refresh-токен и аннулирует старый. Это повышает безопасность: если старый refresh-токен скомпрометирован, злоумышленник не сможет его использовать повторно, так как он уже недействителен. Ротация является рекомендуемой практикой в современных протоколах.

¶Способы хранения и передачи

Безопасность refresh-токена критически важна, так как его компрометация даёт злоумышленнику возможность неограниченно получать новые access-токены.

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

• Веб-приложения: refresh-токен часто хранится в httpOnly-куке (недоступной для JavaScript) или в локальном хранилище браузера (localStorage) с дополнительными мерами защиты. Хранение в localStorage считается менее безопасным из-за уязвимости к XSS-атакам.
• Мобильные приложения: токен хранится в защищённом хранилище операционной системы (Keychain на iOS, Keystore на Android).
• Нативные приложения: для десктопных приложений используются системные хранилища учётных данных.

¶Передача

Refresh-токен передаётся только по защищённому каналу (HTTPS). В протоколе OAuth 2.0 запрос на обновление обычно включает:

• grant_type=refresh_token
• refresh_token=<значение токена>
• client_id и, опционально, client_secret (для конфиденциальных клиентов)

¶Безопасность и уязвимости

¶Основные угрозы

• Перехват refresh-токена: если злоумышленник получает доступ к хранилищу клиента (через XSS, вредоносное ПО, физический доступ к устройству), он может использовать токен для получения access-токенов.
• Replay-атаки: если refresh-токен не имеет ротации, перехваченный токен можно использовать многократно.
• Утечка с сервера: если база данных refresh-токенов скомпрометирована, все активные сессии оказываются под угрозой.

¶Меры защиты

• Ротация refresh-токенов — при каждом обновлении старый токен аннулируется.
• Привязка к клиенту — токен должен быть связан с конкретным клиентским приложением (через client_id или криптографическую привязку).
• Ограничение срока жизни — даже долгоживущие refresh-токены должны иметь разумный срок действия (например, 30 дней).
• Отзыв токенов — сервер должен поддерживать возможность отзыва refresh-токенов (например, при смене пароля или выходе из системы).
• Использование Proof Key for Code Exchange (PKCE) — для публичных клиентов (одностраничные приложения, мобильные приложения) рекомендуется использовать PKCE для защиты от перехвата кода авторизации.

¶Применение в протоколах

¶OAuth 2.0

Refresh-токен является необязательной, но широко используемой частью протокола OAuth 2.0. Он определён в RFC 6749 (раздел 1.5) и используется в гранте authorization_code и password (последний считается устаревшим). В гранте client_credentials refresh-токен обычно не применяется, так как клиент сам является владельцем ресурса.

¶OpenID Connect

В протоколе OpenID Connect (построенном на OAuth 2.0) refresh-токен может использоваться для получения нового ID-токена (содержащего информацию о пользователе) и access-токена.

¶JWT (JSON Web Token)

Refresh-токен может быть реализован как JWT, что позволяет серверу проверять его без обращения к БД, но усложняет отзыв.

¶Примеры реализации

На практике refresh-токены используются в большинстве современных веб-сервисов и API:

• Google API — использует refresh-токены для долгосрочного доступа к сервисам (Gmail, Drive, YouTube).
• GitHub API — выдаёт refresh-токены при использовании OAuth-приложений.
• Microsoft Azure AD — применяет refresh-токены в протоколе OAuth 2.0 для доступа к ресурсам Azure.
• VK API — использует refresh-токены для обновления access-токенов в схеме аутентификации.

¶Критика и альтернативы

Некоторые эксперты критикуют refresh-токены за усложнение архитектуры и увеличение поверхности атаки. Основные альтернативы:

• Короткоживущие access-токены без refresh — клиент вынужден часто перенаправлять пользователя на страницу аутентификации, что снижает удобство.
• Сессионные куки — традиционный подход для веб-приложений, где сессия хранится на сервере. Менее удобен для API и мобильных приложений.
• Device Authorization Grant (OAuth 2.0 для устройств) — для устройств с ограниченным вводом (например, smart TV) используется отдельный поток, где refresh-токен не применяется.

¶Интересные факты

• Refresh-токены не следует путать с refresh-токенами в контексте криптовалют (например, токены ликвидности в DeFi-протоколах) — это разные понятия.
• В спецификации OAuth 2.0 refresh-токен может быть как непрозрачным, так и структурированным (например, JWT), но RFC 6749 не требует определённого формата.
• Некоторые реализации (например, в Keycloak) позволяют настраивать политику ротации refresh-токенов и время их жизни отдельно для каждого клиента.

¶Источники

• RFC 6749 — The OAuth 2.0 Authorization Framework
• RFC 7519 — JSON Web Token (JWT)
• OpenID Connect Core 1.0 Specification
• OAuth 2.0 Threat Model and Security Considerations (RFC 6819)
• Документация по аутентификации Google Identity Platform
• Статья «Refresh Token Rotation» в документации Auth0