OAuth-токен

OAuth-токен — это строка символов, представляющая собой учётные данные для предоставления доступа к определённым ресурсам или действиям от имени пользователя или приложения, выдаваемая в рамках протокола авторизации OAuth (Open Authorization). Токен служит временным, делегированным разрешением, которое позволяет стороннему приложению (клиенту) получать доступ к защищённым данным, хранящимся у поставщика услуг (сервера ресурсов), без необходимости передавать этому приложению логин и пароль пользователя.

История и стандартизация

Протокол OAuth был разработан для решения проблемы делегирования доступа в веб-приложениях. Первая версия (OAuth 1.0) была опубликована в 2010 году, но имела сложности с реализацией и безопасностью. В 2012 году был принят стандарт OAuth 2.0 (RFC 6749), который стал основой для большинства современных систем авторизации. OAuth-токен является центральным элементом этого протокола.

В отличие от OAuth 1.0, где использовались цифровые подписи для каждого запроса, OAuth 2.0 отказался от подписей в пользу использования токенов, передаваемых по защищённому каналу (HTTPS). Это упростило разработку и повысило гибкость, но потребовало строгого соблюдения правил безопасности.

Типы OAuth-токенов

В рамках протокола OAuth 2.0 выделяют два основных типа токенов, которые различаются по назначению и жизненному циклу:

1. Токен доступа (Access Token)

Токен доступа — это основной элемент, который клиент предъявляет серверу ресурсов для получения доступа к защищённым данным. Он представляет собой подписанную или ссылочную строку, которая содержит информацию о разрешениях (scopes), сроке действия и идентификаторе пользователя или клиента.

• Формат: Чаще всего используется JWT (JSON Web Token) — компактный, URL-безопасный токен, содержащий утверждения (claims) в формате JSON. JWT подписывается цифровой подписью, что позволяет серверу ресурсов проверить его подлинность без обращения к серверу авторизации.
• Срок действия: Обычно короткий — от нескольких минут до нескольких часов. Короткое время жизни снижает риски при компрометации токена.
• Передача: Передаётся в HTTP-заголовке Authorization: Bearer <token>.

2. Токен обновления (Refresh Token)

Токен обновления — это долгоживущий токен, который используется для получения нового токена доступа после истечения срока действия старого, без необходимости повторной аутентификации пользователя.

• Срок действия: Может жить дни, недели или даже месяцы, но может быть отозван сервером авторизации в любой момент.
• Хранение: Должен храниться в секрете на стороне клиента, так как его компрометация позволяет злоумышленнику получать новые токены доступа неограниченное время.
• Использование: Отправляется только на сервер авторизации, а не на сервер ресурсов.

Процесс получения OAuth-токена (Гранты)

Протокол OAuth 2.0 определяет несколько типов грантов (flows) — сценариев получения токена. Наиболее распространённые:

## Грант авторизационного кода (Authorization Code Grant)

Самый безопасный и распространённый сценарий для серверных веб-приложений.

1. Пользователь нажимает кнопку «Войти через...» в клиентском приложении.
2. Приложение перенаправляет пользователя на сервер авторизации (например, Google, VK, Яндекс).
3. Пользователь вводит свои логин и пароль на странице сервера авторизации и подтверждает разрешения (например, «доступ к профилю»).
4. Сервер авторизации перенаправляет пользователя обратно в клиентское приложение, передавая в URL временный авторизационный код.
5. Клиентское приложение (на серверной стороне) отправляет этот код вместе со своим секретным ключом (client secret) на сервер авторизации.
6. Сервер авторизации проверяет код и секрет, после чего выдаёт клиенту токен доступа и, опционально, токен обновления.

## Грант неявного типа (Implicit Grant)

Устаревший сценарий, использовавшийся для одностраничных приложений (SPA) и мобильных приложений, где невозможно безопасно хранить секретный ключ. В этом сценарии токен доступа выдавался напрямую после перенаправления, без промежуточного кода. Из-за низкой безопасности (токен виден в URL) этот метод не рекомендуется к использованию.

## Грант учётных данных клиента (Client Credentials Grant)

Используется для сервер-серверной аутентификации, когда приложение обращается к своим собственным ресурсам, а не от имени пользователя. Клиент передаёт свой идентификатор и секретный ключ и получает токен доступа напрямую.

## Грант пароля владельца ресурса (Resource Owner Password Credentials Grant)

Устаревший сценарий, при котором клиент напрямую запрашивает у пользователя логин и пароль и передаёт их серверу авторизации. Используется только в доверенных приложениях (например, официальные мобильные приложения) и не рекомендуется для сторонних сервисов.

Структура и содержимое OAuth-токена (JWT)

Если токен доступа реализован как JWT, его структура состоит из трёх частей, разделённых точками:

1. Header: Содержит информацию о типе токена и алгоритме подписи (например, {"alg": "RS256", "typ": "JWT"}).
2. Payload: Содержит утверждения (claims), которые могут включать:

• sub (subject) — идентификатор пользователя или клиента.
• iss (issuer) — издатель токена (сервер авторизации).
• aud (audience) — получатель токена (сервер ресурсов).
• exp (expiration time) — время истечения срока действия.
• iat (issued at) — время выдачи.
• scope — разрешения, предоставленные токеном (например, read, write).

1. Signature: Цифровая подпись, созданная с использованием секретного ключа или закрытого ключа сервера авторизации. Позволяет серверу ресурсов проверить, что токен не был подделан.

Безопасность и риски

OAuth-токены, несмотря на свою надёжность, подвержены ряду атак:

• Перехват токена (Token Theft): Если злоумышленник получает токен доступа (например, через незащищённое соединение, XSS-атаку или вредоносное ПО), он может использовать его для доступа к данным пользователя до истечения срока действия. Для снижения риска используется короткое время жизни токенов и обязательное использование HTTPS.
• CSRF (Cross-Site Request Forgery): При использовании гранта авторизационного кода атакующий может попытаться заставить пользователя выполнить нежелательные действия. Для защиты используется параметр state в запросе авторизации.
• Утечка токена обновления: Компрометация долгоживущего токена обновления позволяет злоумышленнику получать новые токены доступа неограниченное время. Поэтому токены обновления должны храниться в защищённом хранилище (например, в HttpOnly-куках или на серверной стороне).
• Атака на редирект (Redirect URI Manipulation): Злоумышленник может попытаться подменить URI перенаправления, чтобы перехватить авторизационный код. Сервер авторизации должен строго проверять зарегистрированные URI.

Применение

OAuth-токены широко используются в современных веб-сервисах, мобильных приложениях и API. Примеры:

• Авторизация через социальные сети: Вход на сайт с помощью аккаунта Google, VK, Яндекс, Facebook (организация Meta признана экстремистской и запрещена в РФ) или Apple.
• Доступ к API: Приложения, работающие с данными из облачных сервисов (Google Drive, Dropbox, Яндекс.Диск), получают токен для чтения или записи файлов.
• Микросервисная архитектура: Внутренние сервисы компании могут использовать OAuth-токены для аутентификации и авторизации друг друга.
• Платёжные системы: Сервисы, такие как Stripe или PayPal, используют OAuth-токены для безопасного доступа к платёжным данным.

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

• Протокол OAuth 2.0 не является протоколом аутентификации (проверки личности), а только авторизации (выдачи разрешений). Для аутентификации поверх OAuth 2.0 был разработан стандарт OpenID Connect.
• Токен доступа может быть как «прозрачным» (содержит все данные внутри себя, как JWT), так и «непрозрачным» (просто случайная строка, которую сервер ресурсов должен проверить у сервера авторизации).
• В России OAuth-токены активно используются в экосистемах «Госуслуги», VK, Яндекс, а также в корпоративных системах авторизации.

Источники

• RFC 6749 — The OAuth 2.0 Authorization Framework
• RFC 7519 — JSON Web Token (JWT)
• RFC 6750 — The OAuth 2.0 Authorization Framework: Bearer Token Usage
• Документация OAuth 2.0 на сайте IETF (Internet Engineering Task Force)
• Стандарт OpenID Connect 1.0