OAuth в production: audience атаки, observability и реальные провалы

JWT-валидатор логирует WARN, когда aud claim не содержит ожидаемое значение, затем всё равно принимает токен — “aud содержит client_id вызывающего”. Токен был выпущен для другого приложения. Валидатор только что принял чужой токен — audience bypass, реальный CVE паттерн, замеченный в Microsoft Azure AD в ноябре 2024.

Audience атаки

Когда один authorization server выдаёт токены для нескольких resource server (API-A и API-B), валидатор, принимающий любой валидный aud, может быть эксплуатирован: атакующий, получивший токен для API-A, представляет его API-B.

Правильная проверка aud: содержит ли aud claim токена hard-coded идентификатор этого resource server? Не “содержит ли aud любой известный client_id?” — логическая инверсия, обходящая защиту.

RFC 8707 — Resource Indicators: Клиент указывает resource параметр в /token запросе, называя target resource server. IdP выдаёт токен только с этой audience. Если клиенту нужны токены для обоих API-A и API-B, он вызывает /token дважды с разными resource значениями. Неудобно, но корректно.

Token Exchange (RFC 8693): Resource server, которому нужно вызвать downstream сервис, может представить свой incoming токен и запросить новый токен, валидный у downstream, с суженной audience. Это “least privilege” для service-to-service hop.

Claim cnf (confirmation) сужает привязку дальше: DPoP устанавливает cnf.jkt в thumbprint публичного ключа. Токен с cnf можно использовать только с proof, подписанным соответствующим приватным ключом — audience binding плюс sender binding вместе.

Хранение токенов по типу клиента

Где живут токены — определяет поверхность компрометации:

Browser SPA:

• Access-токен: только JavaScript память (closure или React state). Никогда localStorage — XSS-readable.
• Refresh-токен: httpOnly; Secure; SameSite=Strict cookie — недоступен из JS.
• При page reload: prompt=none silent /authorize round, используя refresh-токен cookie.

Native mobile app:

• Access-токен: OS keychain (iOS Keychain, Android Keystore). Не process memory.
• Refresh-токен: OS keychain, никогда в SharedPreferences или незащищённом storage.

Server-side приложение:

• Access-токен: server session (in-memory или Redis, не клиент).
• Refresh-токен: server session. Клиент никогда не видит ни одного токена.

Machine-to-machine (CI/CD, сервис):

• Использовать client_credentials grant, не user-delegated токены.
• Никогда не embed user access-токены в CI pipelines.

Production observability

Минимально-жизнеспособный OAuth observability dashboard:

refresh_replay_detected_total > 0 — самый actionable alert: означает что хотя бы один refresh-токен был использован двумя различными клиентами — кто-то украл токен.

Четыре реальных OAuth провала

Facebook, сентябрь 2018. Баг в фиче “View As” утёк 50 миллионов access-токенов. Атакующие могли имперсонировать любого из этих пользователей в любом Facebook OAuth клиенте (Spotify, Tinder, Instagram). Fix: инвалидация 90 миллионов токенов.

Slack, февраль 2017. Misconfigured OAuth redirect URI в third-party Slack app позволил атакующему фишингом украсть authorization code workspace owner. Атакующий эскалировал до full admin access. Fix: URI валидация, enforcement exact-match redirect URI на уровне IdP.

GitHub Enterprise, 2021. Баг в PKCE verification позволил downgrade атаки против старых клиентов. Исправлено в patch release.

Microsoft Azure AD, ноябрь 2024. Token-validation cache poisoning уязвимость позволила crafted токену обойти aud валидацию ~30 минут на cached negative response. Fix за несколько часов. Root cause: negative-response кеш не различал “aud не найден” от “aud явно отклонён”.

Паттерн: каждый инцидент вовлекал одну пропущенную или buggy обязательную проверку. Industry ответ на все четыре был одинаков — больше обязательных проверок, короче TTL, шире observability.