Cyber Security Academy · Урок

Потоки OAuth 2.0

Разрешения на авторизацию и токены

«Потоки OAuth 2.0» — бесплатный урок Cyber Security Academy на CoddyKit. Это урок 1 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения Cyber Security Academy, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс Cyber Security Academy содержит 4 уроков всего.

Что на самом деле решает OAuth 2.0

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

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

Специалистам по защите следует помнить: один только OAuth не подтверждает личность пользователя. Считать токен доступа доказательством входа в систему — классическая ошибка, которую устраняет OIDC.

Четыре роли

В каждом потоке OAuth участвуют четыре роли. Для моделирования угроз крайне важно правильно их сопоставить.

Владелец ресурса — пользователь, которому принадлежат данные.
Клиент — приложение, запрашивающее доступ.
Сервер авторизации (AS) — выдает токены после получения согласия.
Сервер ресурсов (RS) — API, хранящий защищенные данные и проверяющий токены.

Между этими ролями проходят границы доверия. Скомпрометированный клиент или слишком разрешающий AS подрывает всю цепочку.

Roles:
  Resource Owner  -> grants consent
  Client          -> requests + uses tokens
  Authorization Server -> issues tokens
  Resource Server -> validates tokens

Предоставление кода авторизации

Предоставление кода авторизации — рекомендуемый поток для веб-приложений и мобильных приложений. Он отделяет перенаправление пользователя от секретного обмена токенами.

Пользователь перенаправляется в AS для аутентификации и предоставления согласия.
AS возвращает короткоживущий code на зарегистрированный URI перенаправления.
Клиент обменивает код на токены через обратный канал, на стороне сервера.

Поскольку токены получаются через обратный канал, они никогда не появляются в адресной строке или истории браузера.

GET /authorize?response_type=code
  &client_id=app123
  &redirect_uri=https://app.example/cb
  &scope=read:profile
  &state=xyz

// then back-channel:
POST /token  grant_type=authorization_code&code=...

PKCE: доказательство владения ключом при обмене кодом

PKCE (RFC 7636) усиливает предоставление кода авторизации и теперь рекомендуется для всех клиентов, включая конфиденциальные.

Клиент создает случайный code_verifier и отправляет его хеш как code_challenge.
При обмене токена он должен предъявить исходный верификатор.

Это связывает код с исходным запросившим его клиентом и не позволяет злоумышленнику, перехватившему код авторизации, обменять его на токены.

code_verifier  = random 43-128 chars
code_challenge = BASE64URL(SHA256(verifier))

/authorize ... &code_challenge=...&code_challenge_method=S256
/token     ... &code_verifier=<original>

Предоставление учетных данных клиента

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

Клиент проходит аутентификацию с помощью собственных учетных данных и получает токен доступа.
Согласие пользователя не требуется, а токен обновления, как правило, не выдается.

Жестко ограничивайте область действия этих токенов и регулярно меняйте секреты клиента. Никогда не используйте этот поток для выдачи себя за конечных пользователей.

POST /token
  grant_type=client_credentials
  client_id=service-a
  client_secret=***
  scope=orders:read

Токены доступа и токены обновления

OAuth выдает два основных типа токенов с совершенно разными сроками действия и правилами обращения.

Токен доступа — короткоживущий токен, отправляемый серверу ресурсов при каждом вызове. Считайте его учетными данными предъявителя.
Токен обновления — долгоживущий токен, используемый только для обращения к AS с целью получения новых токенов доступа.

Токены обновления представляют большую ценность. Храните их безопасно, привязывайте к клиенту и поддерживайте их отзыв.

POST /token
  grant_type=refresh_token
  refresh_token=<long-lived>
  client_id=app123

Токены на предъявителя и передача данных

Большинство токенов доступа OAuth — это токены на предъявителя: любой, у кого есть токен, может его использовать, как наличные.

Всегда передавайте их по TLS; никогда не включайте их в URL, где они попадут в журналы и заголовки источника.
Передавайте их в заголовке Authorization.
Для API высокого риска рассмотрите токены, ограниченные отправителем (DPoP, mTLS).

Authorization: Bearer eyJhbGciOiJSUzI1NiIs...

// AVOID:
GET /api/data?access_token=...   // leaks in logs

Неявное предоставление объявлено устаревшим

Устаревший тип неявного предоставления возвращал токены непосредственно во фрагменте URI перенаправления. Теперь его использование не рекомендуется в документе BCP по безопасности OAuth 2.0, а в OAuth 2.1 оно удалено.

Токены утекали через историю браузера, заголовки источника и журналы.
Отсутствие обратного канала означало менее надежную аутентификацию клиента.

Вместо этого для SPA используйте код авторизации с PKCE.

Параметр state и защита от CSRF

Параметр state защищает этап перенаправления от CSRF. Клиент создает случайное значение, сохраняет его в сеансе и проверяет при обратном вызове.

Если возвращенный state не совпадает, отклоните ответ.
Это не позволяет атакующему внедрить собственный код авторизации в сеанс жертвы.

before:  session.state = randomNonce()
/authorize ... &state=<nonce>

on callback:
  if (req.state !== session.state) reject()

Области доступа и минимально необходимые привилегии

Области доступа определяют степень доступа, предоставляемого токеном. На каждом этапе применяйте принцип минимальных привилегий.

Запрашивайте только те области доступа, которые нужны функции (read:profile, а не admin).
Серверы ресурсов должны проверять область доступа для каждой конечной точки, а не просто доверять действительному токену.

Слишком широкое согласие — распространенный риск в реальных системах: пользователи одобряют приложения, которые запрашивают намного больше разрешений, чем требуется.

Распространенные ошибки настройки OAuth

Большинство инцидентов OAuth вызвано настройками, а не самим протоколом.

Сопоставление при открытом перенаправлении или неточная проверка URI перенаправления позволяют злоумышленникам красть коды.
Отсутствие state или PKCE делает возможными CSRF и внедрение кода.
Долгоживущие токены доступа без возможности отзыва.
Использование токена доступа как утверждения аутентификации.

Регистрируйте точные URI перенаправления и строго проверяйте их.

redirect_uri allowlist:
  EXACT: https://app.example/cb
  NOT:   https://app.example/*  (too broad)

Быстрая проверка: защита аутентификации SPA

Выберите правильный современный поток для описанного ниже сценария.

Итоги: потоки OAuth 2.0

Основные выводы:

OAuth 2.0 — это делегированная авторизация, а не аутентификация.
Четыре роли: владелец ресурса, клиент, сервер авторизации и сервер ресурсов.
Код авторизации + PKCE — стандартный вариант для веб-приложений, мобильных приложений и SPA.
Учетные данные клиента предназначены для доступа между машинами.
Защищайте систему с помощью state, строгой проверки URI перенаправления, краткоживущих токенов доступа и повсеместного использования TLS.
Неявное предоставление и предоставление по паролю объявлены устаревшими.

Часто задаваемые вопросы

Урок «Потоки OAuth 2.0» бесплатный?

Да — полный текст урока «Потоки OAuth 2.0» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс Cyber Security Academy, подпишись на CoddyKit PRO. Курс Cyber Security Academy содержит 4 уроков всего.

Чему я научусь в уроке «Потоки OAuth 2.0»?

Разрешения на авторизацию и токены Ты практикуешь Cyber Security Academy с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.

Нужен ли мне опыт, чтобы начать Cyber Security Academy?

Предыдущий опыт не требуется. Cyber Security Academy на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 1 из 4.

Сколько времени занимает урок «Потоки OAuth 2.0»?

Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.

Можно ли писать и запускать код в этом уроке Cyber Security Academy?

Да. Каждый урок Cyber Security Academy включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.

Все уроки этого курса

← Назад к Cyber Security Academy