Authorization Code Flow

Authorization Code Flow — это один из протоколов авторизации, определённых в спецификации OAuth 2.0, предназначенный для получения доступа к защищённым ресурсам от имени пользователя сторонним приложением (клиентом) через сервер авторизации. Данный поток считается наиболее безопасным и рекомендуемым для приложений, способных безопасно хранить секретный ключ клиента (confidential clients), таких как веб-серверные приложения, серверные API и мобильные приложения с серверной частью. Основное отличие Authorization Code Flow от других потоков OAuth 2.0 (например, Implicit Flow) заключается в использовании промежуточного кода авторизации, который обменивается на токен доступа только после подтверждения сервером авторизации, что клиент является легитимным владельцем секретного ключа.

История и контекст

Протокол OAuth 2.0, в рамках которого определён Authorization Code Flow, был разработан рабочей группой IETF (Internet Engineering Task Force) и опубликован как RFC 6749 в октябре 2012 года. Он пришёл на смену более ранней версии OAuth 1.0, которая была сложнее в реализации и требовала подписывания каждого запроса. Authorization Code Flow стал стандартом де-факто для безопасной делегированной авторизации в веб-приложениях и мобильных приложениях, так как он отделяет процесс получения токена доступа от процесса аутентификации пользователя, снижая риск перехвата токена.

Участники потока

В Authorization Code Flow участвуют три основные стороны:

Ресурсный владелец (Resource Owner) — пользователь, который предоставляет доступ к своим защищённым данным (например, к фотографиям, контактам или файлам).
Клиент (Client) — приложение, запрашивающее доступ к данным от имени владельца ресурса. В контексте данного потока клиент должен быть конфиденциальным (confidential client), то есть способным безопасно хранить свой секретный ключ (client secret).
Сервер авторизации (Authorization Server) — сервер, который аутентифицирует владельца ресурса, получает его согласие и выдаёт клиенту токен доступа после проверки кода авторизации.
Сервер ресурсов (Resource Server) — сервер, который обслуживает защищённые данные (API). Он проверяет токен доступа, предоставленный клиентом, и, в случае успеха, возвращает запрошенные данные.

Пошаговое описание процесса

Процесс Authorization Code Flow состоит из нескольких последовательных шагов, каждый из которых имеет определённую цель.

1. Инициализация запроса авторизации

Клиент (веб-приложение) перенаправляет пользователя (владельца ресурса) на сервер авторизации. В этом запросе клиент указывает:

response_type=code — указывает, что клиент ожидает код авторизации.
client_id — уникальный идентификатор клиента, зарегистрированного на сервере авторизации.
redirect_uri — URI, на который сервер авторизации перенаправит пользователя после успешной аутентификации.
scope — список запрашиваемых разрешений (например, read, write).
state — уникальное значение, генерируемое клиентом для предотвращения атак CSRF (Cross-Site Request Forgery).

2. Аутентификация владельца ресурса и получение согласия

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

3. Перенаправление с кодом авторизации

После успешной аутентификации и получения согласия сервер авторизации перенаправляет браузер пользователя на redirect_uri, указанный клиентом. В URL-адрес перенаправления добавляются два параметра:

code — одноразовый код авторизации (authorization code), который действует короткое время (обычно от нескольких секунд до нескольких минут).
state — то же значение, что было отправлено в шаге 1. Клиент должен проверить, что значение state совпадает с отправленным, чтобы убедиться, что ответ не был подменён.

4. Обмен кода на токен доступа

Клиент, получив код авторизации, отправляет POST-запрос на сервер авторизации (на endpoint /token) напрямую (без участия браузера пользователя). В этом запросе клиент указывает:

grant_type=authorization_code — тип предоставления.
code — полученный код авторизации.
redirect_uri — тот же URI, что использовался в шаге 1.
client_id и client_secret — идентификатор и секретный ключ клиента. Это ключевой момент безопасности: только конфиденциальный клиент, знающий свой секретный ключ, может успешно выполнить этот обмен.

5. Выдача токена доступа (и опционально — токена обновления)

Сервер авторизации проверяет код авторизации, аутентифицирует клиента (через client_id и client_secret) и, в случае успеха, выдаёт ответ в формате JSON, содержащий:

access_token — токен доступа (обычно JWT — JSON Web Token).
token_type — тип токена (например, Bearer).
expires_in — время жизни токена доступа в секундах.
refresh_token — опциональный токен обновления, позволяющий клиенту получить новый токен доступа без повторной аутентификации пользователя.

6. Доступ к защищённым ресурсам

Клиент использует полученный access_token для вызова API сервера ресурсов. Токен включается в HTTP-заголовок Authorization в формате Bearer <token>. Сервер ресурсов проверяет токен (например, проверяет его подпись, срок действия и область действия) и, в случае успеха, возвращает запрошенные данные.

Безопасность и преимущества

Authorization Code Flow считается безопасным по нескольким причинам:

Разделение каналов: Код авторизации передаётся через браузер пользователя, а токен доступа — через прямой канал между клиентом и сервером авторизации. Это предотвращает перехват токена в браузере или на стороне пользователя.
Использование секретного ключа: Только клиент, знающий свой client_secret, может обменять код на токен. Это снижает риск кражи токена при компрометации браузера.
Одноразовый код: Код авторизации действителен только один раз и на короткое время, что затрудняет его повторное использование.
Защита от CSRF: Параметр state защищает от атак межсайтовой подделки запросов.

Разновидности и модификации

PKCE (Proof Key for Code Exchange)

Для публичных клиентов (public clients), таких как одностраничные приложения (SPA) или мобильные приложения, которые не могут безопасно хранить секретный ключ, используется расширение PKCE (RFC 7636). В этой модификации клиент генерирует криптографический ключ (code verifier) и передаёт его хэш (code challenge) на этапе запроса авторизации. При обмене кода на токен клиент предоставляет исходный code_verifier, который сервер авторизации проверяет. PKCE добавляет дополнительный уровень защиты даже при отсутствии client_secret.