OAuth 2.0

OAuth 2.0 — протокол делегирования доступа. Он позволяет приложению получить токен для обращения к защищённому ресурсу, не передавая этому приложению пароль пользователя.

Стандарт

В потоке участвуют:

• Resource owner — пользователь или другая сторона, владеющая ресурсом.
• Client — приложение, запрашивающее доступ.
• Authorization server — сервер, который аутентифицирует пользователя и выдаёт токены.
• Resource server — API, которое проверяет Access Token.

OAuth 2.0 сам по себе не определяет формат данных о личности пользователя. Для этого используется OpenID Connect.

Практика

Приложение обычно перенаправляет пользователя на authorization server, получает временный authorization code и обменивает его на токены. Для браузерных приложений этот обмен выполняется с PKCE.

Access Token передаётся API в заголовке:

Authorization: Bearer ACCESS_TOKEN

Как выглядит запрос доступа

Клиент не передаёт пароль пользователя API. Вместо этого он просит authorization server выполнить вход и вернуть ограниченный результат. В Authorization Code Flow результатом первого шага является временный код, а не Access Token. Код затем обменивается на токены через token endpoint.

Приложение -> Authorization Server: запрос входа
Пользователь -> Authorization Server: вводит данные и подтверждает доступ
Authorization Server -> Приложение: authorization code
Приложение -> Authorization Server: code + параметры клиента
Authorization Server -> Приложение: ID Token / Access Token
Приложение -> Resource Server: Bearer Access Token

Такое разделение важно. Страница входа и проверка личности находятся у authorization server, а проверка доступа к конкретному ресурсу остаётся у API. Валидный токен подтверждает условия его выпуска, но не означает автоматически, что пользователь может читать любую запись или выполнять любую операцию.

Что OAuth 2.0 не решает

OAuth не задаёт модель ролей внутри вашего приложения. Он не определяет, как хранить локальную учётную запись, как устроены роли администратора и как проверять право на конкретный заказ. Эти решения принимаются в приложении после проверки токена.

OAuth также не заменяет защиту Redirect URI, PKCE и хранение секретов. Ошибка в этих частях может свести пользу протокола к нулю.

Типичные ошибки

Использовать ID Token для API

ID Token предназначен для клиента OIDC и описывает результат аутентификации. API должен получать Access Token. Разницу подробно объясняет статья о токенах.

Передавать пароль приложению

Приложение не должно собирать пароль пользователя, чтобы затем отправить его в Authoriza. Пользователь вводит данные на стороне authorization server, а приложение получает результат стандартного flow.

Считать декодирование токена проверкой

JWT можно прочитать без ключа подписи. API должно проверить подпись, iss, aud и exp, а не только вывести payload на экран.

Как проверить результат

• приложение перенаправляет пользователя на Authoriza;
• после входа возвращается authorization code, а не пароль;
• приложение обменивает code на токены через библиотеку или SDK;
• Access Token передаётся только предназначенному для него API;
• API проверяет подпись и обязательные claims;
• бизнес-проверка прав выполняется после проверки токена.

OAuth и локальная сессия приложения

OAuth не обязан создавать сессию в вашем приложении. После успешного обмена приложение само решает, как связать внешний субъект с локальной записью и как хранить состояние браузера. Для server-side приложения это обычно защищённая cookie с серверной сессией. Для SPA это может быть сессия SDK, но её модель хранения нужно рассматривать как часть threat model.

Из этого следуют две независимые операции:

1. проверить, что токен выпущен доверенным issuer для нужного клиента;
2. решить, разрешена ли конкретная операция локальной политикой приложения.

Не объединяйте их в одну проверку token exists. Наличие строки в заголовке не подтверждает ни подлинность, ни право на действие.

Почему authorization code лучше прямой передачи токена

При Authorization Code Flow токен выдаётся после отдельного обмена и может быть защищён PKCE. Access Token не находится в URL callback. Это уменьшает риск попадания токена в историю браузера, referer и журналы reverse proxy. Сам authorization code также должен иметь короткий срок жизни и использоваться один раз.

Когда OAuth не является подходящим объяснением

Если задача состоит только в проверке локальной роли уже вошедшего пользователя, OAuth не заменяет policy engine. Если сервисы обмениваются данными без пользователя, нужно отдельно подтвердить поддержку machine-to-machine flow в конкретной конфигурации Authoriza. Не следует автоматически переносить Client Credentials из документации другого провайдера.

Минимальный checklist перед интеграцией

• определить, кто будет resource server;
• выбрать Public или Confidential client;
• зарегистрировать точный Redirect URI;
• выбрать Authorization Code Flow;
• добавить PKCE для Public client;
• определить scopes;
• решить, где создаётся локальная сессия;
• определить, как API проверяет Access Token;
• подготовить обработку отказа пользователя и истечения сессии.

Как это связано с Authoriza

Если вы выбираете Authoriza как authorization server и OIDC provider, приложение создаётся как подключение внутри проекта. Тип public не использует секрет, а confidential предназначен для backend, который может хранить client_secret.

Чем Authoriza может быть полезна

Если вы не хотите самостоятельно поддерживать сервер авторизации и обмен кодов на токены, Authoriza предоставляет готовый OIDC-интерфейс. Следующий шаг зависит от задачи: изучите OpenID Connect или перейдите к быстрому старту.