OAuth in production: audience attacks, observability, and real failures

A JWT validator logs a WARN when the aud claim does not contain the expected value, then proceeds to accept the token anyway because “aud contains the caller’s client_id.” The token was issued for a different application. The validator just accepted a token intended for someone else — audience bypass, a real CVE pattern seen at Microsoft Azure AD in November 2024.

Audience attacks

When one authorization server issues tokens for multiple resource servers (API-A and API-B), a validator that accepts any valid aud can be exploited: an attacker who obtains a token for API-A presents it to API-B.

The correct aud check: does the token’s aud claim contain this resource server’s hard-coded identifier? Not “does aud contain any known client_id?” — a logical inversion that bypasses the protection.

RFC 8707 — Resource Indicators: The client specifies a resource parameter in the /token request, naming the target resource server. The IdP mints a token with that audience only. If the client needs tokens for both API-A and API-B, it calls /token twice with different resource values. Inconvenient but correct.

Token Exchange (RFC 8693): A resource server that needs to call a downstream service can present its incoming token and request a new token valid at the downstream, with a narrowed audience. This is “least privilege” for service-to-service hops.

The cnf (confirmation) claim also narrows binding: DPoP sets cnf.jkt to the public key thumbprint. A token with cnf can only be used with proof signed by the corresponding private key — audience binding plus sender binding together.

Token storage by client type

Where tokens live determines their exposure surface:

Browser SPA:

• Access token: JavaScript memory only (closure or React state). Never localStorage — XSS-readable.
• Refresh token: httpOnly; Secure; SameSite=Strict cookie — inaccessible from JS.
• On page reload: prompt=none silent /authorize round using the refresh token cookie.

Native mobile app:

• Access token: OS keychain (iOS Keychain, Android Keystore). Not process memory.
• Refresh token: OS keychain, never in SharedPreferences or unprotected storage.

Server-side app:

• Access token: server session (in-memory or Redis, not the client).
• Refresh token: server session. Client never sees either token.

Machine-to-machine (CI/CD, service):

• Use client_credentials grant, not user-delegated tokens.
• Never embed user access tokens in CI pipelines.

Production observability

A minimum OAuth observability dashboard:

refresh_replay_detected_total > 0 is the most actionable alert: it means at least one refresh token was used by two distinct clients — someone stole a token.

Four real-world OAuth failures

Facebook, September 2018. A bug in the “View As” feature exposed 50 million access tokens. Attackers could impersonate any of those users at any Facebook OAuth client (Spotify, Tinder, Instagram). Fix: invalidate 90 million tokens.

Slack, February 2017. A misconfigured OAuth redirect URI in a third-party Slack app let an attacker phish a workspace owner’s authorization code. The attacker escalated to full admin access. Fix: URI validation, required redirect URI exact-match enforcement at the IdP level.

GitHub Enterprise, 2021. A bug in PKCE verification allowed downgrade attacks against older clients. Fixed in a patch release.

Microsoft Azure AD, November 2024. A token-validation cache poisoning vulnerability let a crafted token bypass aud validation for ~30 minutes on cached negative responses. Fixed within hours. Root cause: the negative-response cache did not distinguish “aud not found” from “aud explicitly rejected.”

The pattern: every incident involved one skipped or buggy mandatory check. The industry response to all four was the same — more mandatory checks, shorter TTLs, wider observability.