OAuth 2.0 давно стал стандартным способом организации доступа к API в мобильных и веб-приложениях. Но на практике у разработчиков часто возникают вопросы: как именно работает Authorization Code Flow, зачем нужен PKCE и какую роль играют scopes при ограничении прав доступа.
В этой статье разберем базовую логику работы OAuth 2.0 с точки зрения разработчика: как клиент получает доступ к защищенным ресурсам, какие роли участвуют в процессе и какие механизмы используются для защиты от типовых web-атак.
Что такое OAuth 2.0 и какую задачу он решает?
OAuth 2.0 — это стандартный отраслевой протокол авторизации. Он определяет, как приложения получают ограниченный доступ к защищенным ресурсам пользователя без передачи его учетных данных. При этом за аутентификацию отвечает Authorization Server, который формально не входит в спецификацию протокола OAuth 2.0.
Для разработчика OAuth 2.0 — это универсальный и безопасный механизм работы с API, применяемый в веб-, мобильных и серверных приложениях.
Основные роли и компоненты OAuth 2.0
Четыре роли в OAuth 2.0:
- Resource Owner (владелец ресурса) — субъект, способный предоставить доступ к защищенному ресурсу (любой пользователь приложения).
- Resource Server (ресурсный сервер) — сервер, на котором хранятся защищенные ресурсы владельца. Он может принимать запросы на ограниченный доступ и отвечать на них с помощью токенов доступа.
- Client (клиент) — приложение, отправляющее запросы на доступ к защищенным ресурсам от имени владельца и с его авторизацией.
- Authorization Server (сервер авторизации) — сервер, выдающий клиенту токены доступа после успешной аутентификации владельца ресурса и авторизации.
Основные компоненты протокола OAuth 2.0:
- Authorization code — временный код, используемый для получения токенов.
- Access token — токен доступа к Resource Server.
- Refresh token — токен для обновления access token.
- Scopes — минимальные права клиента. Могут быть как стандартными (например, all, read, write, profile, email), так и пользовательскими, определяемыми для конкретного API.
- Redirect URI — URI, на который возвращается пользователь после авторизации.
Grant Types в OAuth 2.0 и почему важен Authorization Code
В OAuth 2.0 grant type определяет, каким способом клиент получает access token от Authorization Server. По сути, это описание сценария доверия между пользователем, клиентом и сервером авторизации.
Существует несколько grant type, рассчитанных под определенные типы Client и модели безопасности, поэтому неправильный выбор grant type может привести к повышенным рискам утечки токенов и компрометации доступа к API.
Authorization Code
Рассмотрим в качестве примера мобильное приложение для трекинга тренировок и здоровья FitTrack. В этой системе есть Resource Owner — это пользователь, Authorization Server auth.fittrack.com и Resource Server: api.fittrack.com.
Как работает Authorization Code? Пользователь входит в приложение, его перенаправляют на сервер авторизации, где он проходит аутентификацию и дает согласие на доступ к данным. После этого клиент получает authorization code, который затем обменивается на access_token через отдельный запрос.
Ключевая особенность:
- access token не передается через браузер;
- обмен кода на токен происходит напрямую между клиентом и Authorization Server.
Implicit Grant
Implicit Grant — упрощенный вариант Authorization Code, при котором access token выдается сразу после подтверждения пользователем доступа, без этапа обмена кода.
Как это работает: клиент входит через браузер на одностраничное приложение (SPA) и подтверждает доступ. Authorization Server сразу возвращает access token в URL-фрагменте.
Недостатки:
- токен доступен JavaScript-коду;
- возможна утечка через историю браузера, логи или XSS.
Resource Owner Password Credentials (ROPC)
ROPC передает в открытом виде полученный логин и пароль мобильному приложению через определенные формы на нем. Клиент, в свою очередь, передает эти данные на Authorization Server и получает access token.
Недостатки:
- клиент получает доступ к учетным данным пользователя;
- отсутствует разделение ответственности;
- нарушается базовый принцип OAuth.
Client Credentials
Самый простой grant type среди остальных. Клиент аутентифицируется на сервере авторизации, передавая client id и client secret. В ответ получает access token, с которым уже может получить доступ к нужному сервису.
Например, чтобы работать с сервером аналитики, нужно дать ему доступ к данным компании. Для этого сервер аналитики аутентифицируется через корпоративный OAuth-сервер с помощью client_id и client_secret и получает access token для доступа к API.
Особенности:
- scopes описывают права сервиса, а не пользователя;
- используется в service-to-service взаимодействиях.
Почему Authorization Code — лучший выбор
Authorization Code Flow обеспечивает наиболее безопасную модель авторизации, так как:
- access token не передается через браузер;
- учетные данные пользователя никогда не попадают в клиент;
- минимизируется поверхность атак.
Authorization Code Flow: пошаговый разбор
Authorization Code Flow — это OAuth 2.0 рабочий процесс, который обычно используют в приложениях с серверным компонентом. Авторизация происходит в два этапа: сначала приложение запрашивает код авторизации у конечной точки авторизации. Затем код авторизации отправляется на конечную точку для запроса токена доступа.
Основные этапы
Шаг 1. Запрос на endpoint авторизации.
Приложение отправляет запрос на конечную точку авторизации, который обычно содержит следующие параметры:
- client_id: {your client_id}
- response_type: code
- redirect_uri: { адрес перенаправления, который указывается при создании клиента }
- scope: all
Например:
https://auth.anydomain.com/oauth2/auth?response_type=code&client_id=2145233121810.ndeybd7ykeh6yhwa&redirect_uri=https://client.anydomain.com/callback/oauth2/redirect&scope=all
Шаг 2. Проверка авторизации
Когда пользователь попадает на страницу авторизации, Authorization Server берет управление на себя: проверяет, авторизован ли пользователь, предлагает ему подтвердить запрашиваемые права доступа (scopes).
Если пользователь успешно вошел в систему и дал согласие, сервер авторизации генерирует одноразовый authorization code. Далее Authorization Server делает redirect обратно в клиентское приложение на заранее зарегистрированный redirect_uri, передавая код в параметрах URL.
Вот пример URL-адреса для перенаправления:
https://client.anydomain.com/callback/oauth2/redirect?code=SplxlOBeZQQYbYS6WxSbIA
code —одноразовый код
Шаг 3. Обмен authorization code на access token
Далее токен с code из предыдущего шага отправляется в виде POST-запроса со следующими параметрами:
- grant_type: authorization_code
- redirect_uri: это должен быть ваш URI перенаправления.
- code: код из предыдущего шага.
- client_id и client_secret для использования в базовом методе аутентификации. Представлено в формате base64 как client_id:client_secret
Пример:
POST /token HTTP/1.1 Host: auth.anydomain.com Content-Type: application/x-www-form-urlencoded Authorization: Basic MjE0NTIzMzEyMTgxMC5uZGV5YmQ3eWtlaDZ5aHdhOm15X2NsaWVudF9zZWNyZXQ= grant_type=authorization_code& code=SplxlOBeZQQYbYS6WxSbIA& redirect_uri=https://client.anydomain.com/callback
В ответе получаем access_token, который дает доступ к необходимым данным на стороне Resource Server.
PKCE: зачем он нужен и как работает
PKSE (Proof Key for Code Exchange) — это расширение протокола OAuth 2.0, которое повышает безопасность процесса авторизации. Он защищает авторизационный код от перехвата, что особенно важно для мобильных приложений и одностраничных веб-приложений (SPA).
PKCE использует локально сгенерированную пару code_verifier и code_challenge, связывая запрос кода авторизации с последующим обменом на токен доступа. В результате токен может получить только тот клиент, который инициировал авторизацию, что эффективно снижает риск CSRF-атак.
Основное отличие реализации связки Authorization code flow и PKCE от базового использования Authorization Code Flow заключается в дополнительных параметрах.
Authorization Code Flow с поддержкой PKCE дополняет классический поток авторизации и усиливает его безопасность.
Как работает Authorization Code Flow совместно с PKCE
Поговорим подробнее о приложении FitTrack (iOS/Android) из первого примера. Оно предназначено для отслеживания тренировок и показателей здоровья пользователя.
Приложение взаимодействует с облачным сервисом FitTrack, который состоит из двух компонентов:
- Authorization Server — auth.fittrack.com;
- Resource Server (API) — api.fittrack.com.
В роли Resource Owner выступает пользователь, а в роли OAuth Client — мобильное приложение FitTrack.
Для корректной работы FitTrack запрашивает доступ исключительно к тем данным, которые необходимы для функционирования приложения, а именно:
- profile.read: чтение профиля пользователя;
- workouts.read: чтение истории тренировок;
- workouts.write: добавление новых тренировок.
Пользователь подтверждает только эти действия. Другие операции (например, удаление данных или доступ к медицинским показателям) приложению недоступны.
Шаг 1. Инициация авторизации и генерация PKCE
Перед началом авторизации мобильное приложение локально генерирует:
- code_verifier — криптографически случайную строку;
- code_challenge — результат BASE64URL(SHA256(code_verifier)).
Далее приложение открывает системный браузер и перенаправляет пользователя на endpoint авторизации:
GET https://auth.fittrack.com/oauth2/auth ?response_type=code &client_id=fittrack_mobile &redirect_uri=fittrack://oauth/callback &scope=profile.read workouts.read workouts.write &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM &code_challenge_method=S256
На этом этапе:
- пользователь еще не аутентифицирован;
- access token не выдается;
- Authorization Server сохраняет code_challenge.
Шаг 2. Аутентификация пользователя и выдача authorization code
Authorization Server выполняет следующие действия:
- Проверяет корректность client_id и redirect_uri.
- Аутентифицирует пользователя (логин, пароль, MFA).
- Отображает экран согласия с перечнем scopes.
- После подтверждения создает authorization code.
Пользователь перенаправляется обратно в приложение:
fittrack://oauth/callback?code=SplxlOBeZQQYbYS6WxSbIA
Шаг 3. Обмен authorization code на access token
Получив код, мобильное приложение отправляет POST-запрос на token endpoint:
POST https://auth.fittrack.com/oauth2/token Content-Type: application/x-www-form-urlencoded grant_type=authorization_code& client_id=fittrack_mobile& code=SplxlOBeZQQYbYS6WxSbIA& redirect_uri=fittrack://oauth/callback& code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
И, уже используя полученный access token, мобильное приложение обращается к api.fittrack.com.
Для наглядности ниже приведем общую схему Authorization Code Flow совместно с использованием Proof Key for Code Exchange (PKCE):
OAuth 2.0: коротко о главном
OAuth 2.0 — это стандартный механизм авторизации для доступа к API и защищенным ресурсам. Протокол решает задачу делегирования прав доступа: приложение получает ограниченные полномочия, при этом учетные данные пользователя ему не передаются.
Среди доступных grant types Authorization Code Flow занимает центральное место в большинстве приложений. При совместном использовании с PKCE обеспечивает безопасный обмен токенами в рамках confidential clients, public clients, SPA и мобильных приложений.
Механизм scopes ограничивает уровень доступа клиента через принцип минимально необходимых привилегий на уровне протокола. Безопасная реализация OAuth 2.0 требует корректной проверки scopes на стороне Resource Server.
Актуальные рекомендации по безопасности сводятся к нескольким положениям: применение Authorization Code Flow с PKCE, отказ от устаревших grant types, минимизация объема предоставляемых прав.
