OAuth 2.0.

OAuth 2.0 (RFC 6749) разделяет четыре роли: владелец ресурса (пользователь), клиент (приложение), сервер авторизации, выдающий токены, и сервер ресурсов, на котором размещён API. Клиент получает access token по одному из определённых потоков (grant) — authorization code с PKCE (RFC 7636) для интерактивных приложений, client credentials для вызовов между сервисами, device code (RFC 8628) для устройств с ограниченным вводом — и затем вызывает API, передавая этот токен как bearer-учётные данные. Области (scopes) и audience ограничивают возможности токена.

Рекомендации по безопасности и подводные камни

RFC 9700 (BCP 240, опубликован в январе 2025 года) обобщает практику безопасности OAuth: он объявляет устаревшими implicit grant и resource owner password credentials grant, делает PKCE обязательным для каждого клиента с authorization code и требует точного совпадения redirect URI, чтобы пресечь атаки перехвата кода и open redirect. Поскольку access token — это bearer-учётные данные, привязка их к отправителю с помощью DPoP или взаимного TLS ограничивает повторное использование (replay) после кражи.

Наиболее распространённое злоупотребление на практике — фишинг согласия OAuth (illicit consent grant): вместо кражи паролей злоумышленники регистрируют вредоносное приложение и обманом побуждают пользователей одобрить широкие области. Червь «Google Docs» в мае 2017 года распространился именно так примерно за час, а APT29/Nobelium неоднократно злоупотребляли согласиями Microsoft 365, чтобы сохранять доступ в обход MFA. К мерам защиты относятся рабочие процессы административного согласия, верификация издателя, короткоживущие токены и отзыв неиспользуемых согласий.

flowchart LR
  U[Владелец ресурса] -->|1 авторизация + code_challenge| AS[Сервер авторизации]
  AS -->|2 auth-код через redirect| C[Клиентское приложение]
  C -->|3 код + code_verifier| AS
  AS -->|4 access token| C
  C -->|5 bearer-токен| RS[Сервер ресурсов / API]
  RS -->|6 защищённые данные| C