OAuth — открытый протокол авторизации, который позволяет приложению получить ограниченный доступ к ресурсам пользователя или другой системы без передачи ему основного пароля.
Например, пользователь может разрешить сервису читать определенные данные из другого приложения. Вместо передачи Login и Password сервис получает специальный Access Token с ограниченными правами и сроком действия.
OAuth широко используется в Web Applications, Mobile Apps, API, SaaS, Cloud Services и интеграциях между корпоративными системами.
OAuth решает прежде всего задачу делегирования доступа: пользователь или система разрешает приложению выполнять определенные действия без передачи ему основных Credentials.
Что такое OAuth простыми словами
Представим сервис, которому нужно получить доступ к данным пользователя в другом приложении.
Без OAuth схема могла бы выглядеть небезопасно:
User gives login + password ↓ Third-party application ↓ Access to external service
Приложение узнает основной Password пользователя и потенциально получает слишком широкие возможности.
OAuth предлагает другую модель:
User ↓ grants permission Authorization Server ↓ access token Application ↓ API
Приложение получает Token только с теми Permissions, которые были ему предоставлены.
Для чего нужен OAuth
OAuth используется для:
- делегирования доступа к API;
- подключения сторонних приложений;
- интеграции SaaS-сервисов;
- работы Mobile и Web Applications;
- ограниченного доступа к пользовательским данным;
- Machine-to-Machine интеграций;
- централизованного управления разрешениями.
OAuth — это авторизация, а не аутентификация
Это важное различие.
OAuth в первую очередь отвечает на вопрос:
Что этому приложению разрешено делать?
Authentication отвечает на другой вопрос:
Кто этот пользователь?
Для пользовательского Login поверх OAuth-инфраструктуры часто применяется OpenID Connect.
OAuth и OpenID Connect
OAuth предоставляет механизм делегирования доступа, а OpenID Connect добавляет Identity Layer.
| OAuth | OpenID Connect |
|---|---|
| Authorization | Authentication и Identity |
| Access Token | ID Token плюс OAuth Tokens |
| Доступ к API | Подтверждение личности пользователя |
Поэтому для функции «Войти через внешний аккаунт» обычно требуется не просто OAuth, а соответствующий Authentication Protocol, например OpenID Connect.
Основные роли в OAuth
Типичная OAuth-архитектура включает несколько участников.
| Роль | Назначение |
|---|---|
| Resource Owner | Владелец данных или прав |
| Client | Приложение, запрашивающее доступ |
| Authorization Server | Выдает Tokens после проверки разрешения |
| Resource Server | API, которое принимает Access Token |
Resource Owner
Resource Owner — субъект, который может разрешить доступ к ресурсу.
В пользовательском сценарии это обычно сам пользователь.
Client
Client — приложение, которому нужен доступ.
Это может быть:
- Web Application;
- Mobile App;
- Desktop Application;
- Backend Service;
- интеграционный сервис.
Authorization Server
Authorization Server выполняет процедуру выдачи Tokens.
Он проверяет Client, пользователя и запрошенные Permissions и принимает решение о выдаче Access Token.
Resource Server
Resource Server — API, защищающее данные или операции.
При каждом Request оно проверяет Access Token и определяет, разрешено ли действие.
Access Token
Access Token — Credential, который Client предъявляет Resource Server.
Пример логики:
GET /api/documents Authorization: Bearer ACCESS_TOKEN
API проверяет Token и его Permissions перед обработкой Request.
Bearer Token
Bearer Token работает по принципу: кто владеет действующим Token, тот потенциально может его использовать.
Поэтому Access Token необходимо защищать от утечки.
Почему Access Token нельзя публиковать
Token может предоставлять прямой доступ к API без повторного ввода Password.
Его нельзя:
- записывать в публичные Logs;
- публиковать в Git Repository;
- передавать через незашифрованный канал;
- вставлять в публичный URL без необходимости;
- хранить в открытом виде в исходном коде.
Scope
Scope описывает набор разрешений, который запрашивает Client.
Например:
profile.read calendar.read calendar.write
Приложению для чтения календаря не нужно автоматически выдавать право удалять события.
Принцип Least Privilege в OAuth
Client должен получать минимально необходимый Scope.
Чем шире Permissions Token, тем больше потенциальный ущерб при его компрометации.
Consent
В пользовательском сценарии Authorization Server может показать экран согласия.
Например:
Application requests: - Read your profile - Read your calendar
Пользователь принимает или отклоняет запрос.
Почему Consent не всегда показывается
В корпоративной инфраструктуре Administrator может заранее разрешить определенные Applications и Scopes.
Кроме того, пользователь может ранее уже дать согласие.
Authorization Code
Authorization Code — временный одноразовый код, который Client получает после успешной Authorization.
Затем Backend обменивает Code на Access Token.
Browser ↓ authorization Authorization Server ↓ code Client Backend ↓ token request Authorization Server ↓ access token
Зачем нужен промежуточный Code
Он позволяет не передавать Access Token непосредственно через Browser Redirect в типичной серверной архитектуре.
Client получает Token через отдельный защищенный Server-to-Server Request.
Authorization Code Flow
Упрощенный процесс:
- Client перенаправляет пользователя на Authorization Server.
- Пользователь проходит Authentication.
- Пользователь подтверждает Permissions.
- Authorization Server возвращает Code.
- Client обменивает Code на Token.
- Client обращается к API с Access Token.
Redirect URI
После завершения Authorization Server должен вернуть пользователя в Client Application.
Для этого используется заранее зарегистрированный Redirect URI.
Например:
https://app.example.com/oauth/callback
Почему Redirect URI нужно проверять строго
Если злоумышленник может подменить Redirect URI, Authorization Code потенциально может быть отправлен на его сайт.
Поэтому Authorization Server должен использовать заранее разрешенные и корректно сопоставляемые Addresses.
State
Параметр State помогает Client связать входящий OAuth Response с исходной Session и защищаться от ряда сценариев подмены запроса.
Client генерирует непредсказуемое значение, отправляет его в Authorization Request и проверяет при возврате.
PKCE
PKCE, или Proof Key for Code Exchange, усиливает Authorization Code Flow.
Client создает случайный Code Verifier и производное значение Code Challenge.
При обмене Authorization Code на Token требуется доказать владение исходным Verifier.
Зачем нужен PKCE
Если злоумышленник перехватит Authorization Code, одного Code будет недостаточно для получения Token без соответствующего Code Verifier.
PKCE особенно важен для Public Clients, которые не могут надежно хранить Client Secret.
Public Client
Public Client — приложение, которое не может безопасно хранить постоянный Secret.
Примеры:
- Mobile Application;
- Desktop Application;
- часть Browser-based Applications.
Пользователь имеет доступ к программному коду и среде выполнения, поэтому встроенный Secret нельзя считать действительно секретным.
Confidential Client
Confidential Client имеет Backend Environment, где Credentials можно хранить надежнее.
Например, Server-side Web Application может хранить Client Secret в Secret Manager.
Client ID
Client ID идентифицирует приложение в Authorization Server.
Сам по себе Client ID обычно не является секретом.
Client Secret
Client Secret используется некоторыми Confidential Clients для подтверждения своей Identity перед Authorization Server.
Его нельзя помещать в Frontend Code или Mobile Application, где пользователь способен его извлечь.
Refresh Token
Access Token обычно имеет ограниченный Lifetime.
Refresh Token позволяет получить новый Access Token без повторной интерактивной Authentication пользователя.
Refresh Token ↓ Authorization Server ↓ New Access Token
Почему Refresh Token чувствительнее
Он часто живет дольше Access Token и позволяет получать новые Tokens.
Поэтому компрометация Refresh Token может дать злоумышленнику длительный доступ.
Refresh Token Rotation
При Rotation после использования Refresh Token сервер выдает новый и делает предыдущий недействительным или ограничивает его дальнейшее использование.
Это помогает обнаруживать и ограничивать повторное использование украденного Token.
Token Lifetime
Короткий срок действия Access Token уменьшает окно его полезности после утечки.
Но слишком короткий Lifetime увеличивает количество операций Refresh.
Необходим баланс между Security и Reliability.
Token Revocation
При компрометации пользователя или Client необходимо иметь возможность отозвать доступ.
Например, пользователь может удалить разрешение приложения, после чего Refresh Token перестает работать.
Logout и OAuth
OAuth не следует воспринимать как полный протокол пользовательского Logout.
У Client, Authorization Server и других приложений могут существовать отдельные Sessions.
Управление выходом зависит от применяемой Identity Architecture.
OAuth и SSO
OAuth часто встречается рядом с SSO, но не является синонимом единого входа.
Для SSO пользователь должен пройти Authentication, а приложения — получить подтверждение его Identity.
Эту задачу может выполнять OpenID Connect.
OAuth и MFA
MFA может использоваться на Authorization Server при Authentication пользователя.
Сам OAuth не определяет, должен ли пользователь вводить Password, использовать Security Key или проходить MFA.
OAuth и 2FA
Аналогично двухфакторная Authentication является политикой Identity Provider или Authorization Server.
После успешной проверки OAuth Flow продолжает процедуру выдачи разрешений и Tokens.
OAuth и IAM
OAuth является одним из механизмов, используемых IAM Infrastructure.
IAM управляет Identities, Roles и Access Lifecycle, а OAuth позволяет передавать ограниченный доступ Applications и APIs.
OAuth и API
Одно из основных применений OAuth — защита API.
Resource Server принимает Requests только при наличии действующего Token с подходящими Permissions.
Client ↓ Access Token API Gateway ↓ Backend API
OAuth и API Gateway
API Gateway может централизованно проверять Token до передачи Request Backend.
Он может валидировать:
- Issuer;
- Audience;
- Expiration;
- Scope;
- Signature.
JWT и OAuth
OAuth не требует, чтобы Access Token обязательно был JWT.
Token может быть структурированным или непрозрачным в зависимости от архитектуры Authorization Server.
JWT Access Token
Если Token имеет формат JWT, Resource Server может в некоторых архитектурах проверять его подпись и Claims локально.
При этом необходимо корректно проверять Issuer, Audience, Lifetime и разрешенный алгоритм.
Opaque Token
Opaque Token выглядит для Client как случайная строка.
Resource Server может обращаться к Authorization Infrastructure за информацией о его состоянии или использовать другой предусмотренный механизм проверки.
Token Introspection
Introspection позволяет Resource Server запросить Authorization Server и определить, действителен ли Token и какие параметры с ним связаны.
Scope и Role
Scope и Role связаны с Authorization, но не всегда являются одним и тем же.
Scope часто описывает, что Client может запросить у API, а Role может описывать положение пользователя внутри бизнес-системы.
Claims
Claims — утверждения, содержащие информацию в Token или Identity Context.
Например:
subject: user-125 scope: documents.read issuer: auth.example.com
Приложение не должно доверять Claims без проверки Token.
Audience
Audience определяет, для какого Resource Server предназначен Token.
API не должно принимать Token, выпущенный для совершенно другого сервиса только потому, что подпись корректна.
Issuer
Issuer указывает, какой Authorization Server выпустил Token.
Resource Server должен доверять только ожидаемому Issuer.
Expiration
Expired Token должен быть отклонен.
Проверка срока действия является базовой частью Token Validation.
OAuth для Web Application
Server-side Web Application может использовать Authorization Code Flow.
Backend хранит Tokens и обрабатывает Callback, а Browser получает только Application Session.
OAuth для Mobile Application
Mobile App является Public Client и не должна полагаться на встроенный Client Secret как на надежную защиту.
Для подобных сценариев особенно важны Authorization Code Flow и PKCE.
OAuth для SPA
Browser Application также работает в среде, где долгоживущий Secret нельзя считать защищенным.
Token Storage и защита от XSS становятся критичными архитектурными вопросами.
Почему Token в Local Storage требует осторожности
При успешной XSS-атаке JavaScript может получить доступ к данным, доступным странице.
Поэтому способ хранения Tokens должен проектироваться вместе с Web Security Architecture.
Backend for Frontend
Один из подходов заключается в использовании Backend, который хранит OAuth Tokens на серверной стороне, а Browser работает с защищенной Application Session.
Это уменьшает прямое присутствие чувствительных Tokens в Frontend.
Client Credentials Flow
Для Machine-to-Machine сценария пользователь может вообще отсутствовать.
Один Service аутентифицируется как Client и получает Access Token для другого API.
Service A ↓ client authentication Authorization Server ↓ token Service A → API B
OAuth для микросервисов
Microservice может получать Token с ограниченным Scope и использовать его для обращения к другому Service.
Это лучше, чем хранить один общий Administrator API Key во всей инфраструктуре.
Service Account и OAuth
Техническая Identity может использовать OAuth-подобную Token Infrastructure для Machine-to-Machine Access.
Права Service должны соответствовать принципу Least Privilege.
OAuth и Secret Manager
Client Secret и другие долговременные Credentials необходимо хранить в защищенном Secret Manager, а не в Source Code.
Почему нельзя хранить Client Secret в Git
Git Repository может быть скопирован, опубликован или доступен большому числу разработчиков.
Даже после удаления Secret он может остаться в истории Commit.
OAuth и CI/CD
Automation Pipeline может использовать Service Identity для доступа к API.
Лучше выдавать короткоживущие Credentials, чем хранить постоянный Token в CI Configuration.
OAuth и Cloud
Cloud Applications часто используют Tokens для доступа к APIs и SaaS.
При этом необходимо контролировать, какие Applications получили Consent и какие Permissions им предоставлены.
Consent Phishing
Злоумышленник может создать приложение и убедить пользователя дать ему широкие OAuth Permissions.
В таком случае Password пользователя может вообще не быть украден, но вредоносный Client получает легитимный Token.
Почему MFA не всегда спасает от Consent Phishing
Пользователь может корректно пройти MFA и после этого самостоятельно разрешить вредоносному приложению доступ.
Поэтому организация должна контролировать App Registration и Consent Policies.
OAuth App Governance
В корпоративной среде полезно отслеживать:
- новые Applications;
- запрошенные Scopes;
- Admin Consent;
- Publisher Information;
- неиспользуемые Grants;
- подозрительные OAuth Tokens.
Admin Consent
Для особо чувствительных Permissions организация может запретить обычным пользователям выдавать Consent самостоятельно.
Разрешение предоставляет Administrator после проверки приложения.
OAuth и Zero Trust
OAuth Tokens не должны означать безусловное доверие.
API по-прежнему проверяет Audience, Scope и другие параметры, а IAM может учитывать Risk и состояние Identity.
Token Theft
Если Access Token украден, злоумышленник может попытаться использовать его до Expiration или Revocation.
Поэтому защищать нужно не только Password, но и Tokens.
Откуда могут утечь Tokens
Типичные причины:
- Application Logs;
- Browser Storage;
- Malware;
- небезопасный Redirect;
- Source Code;
- неправильно защищенная Database;
- Diagnostic Dump.
HTTPS и OAuth
OAuth взаимодействия должны выполняться через защищенный транспорт там, где передаются чувствительные Credentials и Tokens.
Без TLS злоумышленник на сетевом пути может попытаться перехватить их.
OAuth и CORS
CORS относится к Browser Security Policy и не является механизмом OAuth Authentication.
Разрешение CORS не означает, что Request авторизован, а запрет CORS не заменяет проверку Token на API.
OAuth и CSRF
OAuth Flow необходимо защищать от подмены пользовательской Session и Authorization Response.
Для этого используются предусмотренные протоколом механизмы, в том числе State в подходящих сценариях, а также корректная Session Handling.
Redirect URI Attack
Слишком свободное сопоставление Redirect URI может позволить злоумышленнику направить Authorization Result на чужой Endpoint.
Поэтому Wildcard и динамические Redirects требуют особой осторожности.
Open Redirect
Если доверенный Callback позволяет затем перенаправлять пользователя на произвольный URL, это может создавать дополнительный путь для кражи Authorization Data.
Redirect Logic необходимо строго ограничивать.
Authorization Code Interception
Перехваченный Code может быть ценен для атакующего.
PKCE значительно уменьшает риск его использования без Code Verifier.
Replay Attack
Одноразовые Authorization Codes и ограниченный Lifetime уменьшают возможность повторного использования перехваченных данных.
Client и Server должны корректно контролировать жизненный цикл Credentials.
Token Replay
Bearer Access Token в пределах срока действия может быть повторно использован тем, кто его получил.
Для особо чувствительных систем могут применяться дополнительные механизмы привязки Token к Client или Cryptographic Key.
Почему OAuth не заменяет Application Authorization
Даже если API проверило Token, оно должно контролировать доступ к конкретным объектам.
Например, Token пользователя не должен позволять прочитать документ другого клиента только путем изменения ID в URL.
Broken Access Control
OAuth подтверждает наличие определенного Access Context, но ошибки в бизнес-Authorization остаются ответственностью приложения.
OAuth и RBAC
После проверки Token Application может использовать Roles пользователя для принятия решения.
Valid token ↓ Role = accountant ↓ Invoice read allowed
OAuth и ABAC
Кроме Roles можно учитывать Attributes, например Department, Device или Resource Owner.
OAuth Token может предоставить часть необходимых Claims, но итоговую Policy применяет Resource Server.
OAuth и SIEM
Authorization Events являются ценным источником для SIEM.
Полезно контролировать:
- новую регистрацию Client;
- выдачу широкого Consent;
- ошибки Token Exchange;
- аномальное использование Refresh Token;
- Revocation;
- Login и MFA Events Authorization Server.
OAuth и SOC
SOC может расследовать подозрительную активность OAuth Applications.
Например, новый Client неожиданно получает доступ к почте большого количества сотрудников.
OAuth и XDR
XDR способен связывать события Authorization с Email, Endpoint и Cloud Telemetry.
Phishing message ↓ OAuth consent ↓ Token issued ↓ Mass data access
Так обнаруживается атака, которая может происходить без кражи Password.
OAuth и SAML
SAML чаще применяется для Federation и корпоративного Web SSO, а OAuth — для делегированного доступа к APIs.
Они могут сосуществовать в одной IAM Architecture.
OAuth и API Key
API Key обычно является более простой постоянной строкой, идентифицирующей Application или Project.
OAuth предоставляет более развитую модель Tokens, Scopes, Expiration и Delegation.
| API Key | OAuth |
|---|---|
| Простая Credential | Протокол Authorization |
| Часто статический | Tokens могут быть короткоживущими |
| Обычно меньше контекста | Scopes и Delegation |
OAuth и Basic Authentication
Basic Authentication передает пользовательские Credentials или эквивалентные данные при запросах.
OAuth позволяет API работать с отдельным Token вместо основного Password пользователя.
OAuth и мобильные приложения
Mobile Application не должно просить пользователя вводить Password стороннего сервиса непосредственно в собственную форму, если доступ можно получить через стандартный OAuth Authorization Flow.
Пользователь проходит Authentication у доверенного Authorization Server.
System Browser
Для пользовательской Authorization часто предпочтительно использовать доверенный Browser Context, где пользователь видит реальный Domain Authorization Server и может использовать существующую Session и MFA.
Embedded Credentials Form
Если стороннее приложение самостоятельно просит Password к чужому сервису, пользователь не может надежно отличить легитимный Client от Credential Theft.
Именно от такой модели OAuth помогает отказаться.
Типичные ошибки OAuth
- Считать OAuth протоколом Authentication.
- Хранить Client Secret во Frontend.
- Не использовать PKCE для Public Client.
- Слишком широко разрешать Redirect URI.
- Не проверять State и Session Context.
- Выдавать слишком широкие Scopes.
- Хранить Access Token в Logs.
- Не проверять Audience и Issuer.
- Не отзывать Tokens после компрометации.
- Разрешать любой OAuth Client без Governance.
Как безопасно использовать OAuth
Шаг 1. Определить правильный сценарий
Разделите пользовательскую Authentication и API Authorization.
Шаг 2. Использовать стандартный Authorization Flow
Не создавайте собственный обмен Password на Token без необходимости.
Шаг 3. Ограничить Scopes
Client должен получать только необходимые Permissions.
Шаг 4. Использовать PKCE
Особенно для Public Clients.
Шаг 5. Строго настроить Redirect URI
Разрешайте только известные Callback Addresses.
Шаг 6. Защищать Tokens
Не помещайте их в Source Code, публичные Logs или небезопасное Storage.
Шаг 7. Ограничить Lifetime
Используйте разумный срок действия и безопасный Refresh Process.
Шаг 8. Настроить Monitoring
Следите за Consent, Token Usage и подозрительными Clients.
Практический пример
Компания разрабатывает сервис аналитики, которому нужно читать календарь сотрудника для построения статистики встреч.
Небезопасная реализация потребовала бы от пользователя передать сервису Password от корпоративного аккаунта.
Вместо этого используется OAuth.
Пользователь нажимает «Подключить календарь» и перенаправляется на корпоративный Authorization Server.
После Authentication система показывает разрешение:
Analytics application requests: calendar.read
Пользователь подтверждает доступ.
Client получает Authorization Code и обменивает его на Access Token. API принимает Token только для чтения календаря.
У приложения нет права изменять или удалять встречи, потому что такой Scope ему не предоставлен.
Через некоторое время пользователь удаляет интеграцию. Refresh Token отзывается, и сервис больше не может получать новые Access Tokens.
Так OAuth позволяет предоставить ограниченный и управляемый доступ без раскрытия основного Password.
OAuth для бизнеса
Для бизнеса OAuth особенно важен при интеграции SaaS и API. Он позволяет отказаться от практики передачи постоянных пользовательских Password сторонним Applications.
Компания может контролировать Scopes, срок действия Tokens, список разрешенных Clients и историю Consent.
При этом OAuth требует Governance: слишком широкие Permissions или вредоносный Client могут привести к утечке данных даже при включенной MFA.
Преимущества OAuth
- не нужно передавать основной Password приложению;
- ограниченные Scopes;
- короткоживущие Access Tokens;
- возможность Revocation;
- поддержка пользовательских и Machine-to-Machine интеграций;
- централизованное управление Authorization;
- подходит для современных API.
Ограничения OAuth
- сложнее простого API Key;
- ошибки Redirect URI опасны;
- Tokens необходимо защищать;
- OAuth сам по себе не является Authentication;
- широкий Consent может быть рискованным;
- не заменяет Application-level Authorization;
- требует правильного управления Token Lifecycle.
Когда использовать OAuth
OAuth подходит, когда приложение должно получить ограниченный доступ к API от имени пользователя или от имени собственного Service, а передача постоянного Password или универсального API Key нежелательна.
Для подтверждения личности пользователя OAuth обычно дополняют OpenID Connect или другим подходящим Authentication Mechanism.
Связанные термины
| Термин | Связь с OAuth |
|---|---|
| OpenID Connect | Добавляет Authentication и Identity Layer |
| Access Token | Используется Client для доступа к API |
| Refresh Token | Позволяет получать новые Access Tokens |
| Scope | Описывает разрешенный набор действий |
| PKCE | Защищает Authorization Code Flow от перехвата Code |
| SSO | Связан с Identity Federation, но не является самим OAuth |
| IAM | Использует OAuth как один из механизмов управления доступом |
| MFA | Может применяться при Authentication пользователя |
| API | Один из основных ресурсов, защищаемых OAuth Tokens |
| JWT | Один из возможных форматов Token |
| SIEM | Анализирует Authorization и Token Events |
| Zero Trust | Использует ограниченные Identities и проверяемый Access Context |
Краткий итог
OAuth — протокол авторизации и делегирования доступа, позволяющий приложению получить ограниченные права на работу с API без получения основного Password пользователя.
Основными элементами OAuth являются Client, Authorization Server, Resource Server, Access Token и Scope. Для пользовательских приложений широко применяется Authorization Code Flow с PKCE, а для Machine-to-Machine интеграций используются отдельные технические сценарии.
OAuth не следует путать с Authentication и SSO. Для подтверждения личности пользователя обычно используется OpenID Connect или другая Identity Technology. Безопасная OAuth-архитектура требует строгих Redirect URI, защиты Tokens, минимальных Scopes, контроля Consent и централизованного Monitoring.
