OAuth Vulnerabilities and Attack Patterns

OAuth authorization servers must strictly validate the redirect_uri parameter. If the server allows prefix matching or wildcard matching (e.g., accepting any URL starting with "https://app.example.com"), an attacker crafts an authorization request redirecting to "https://app.example.com.attacker.com/steal" or an open redirect on the legitimate domain, stealing the authorization code.

Without CSRF protection, an attacker can initiate an OAuth flow and trick a victim's browser into completing the authorization. The victim inadvertently authorizes the attacker's client. The "state" parameter (RFC 6749) prevents this: the client generates a random state, includes it in the request, and verifies it matches in the callback. A mismatch aborts the flow.

On mobile platforms, malicious apps can register the same custom URI scheme as a legitimate OAuth client and intercept authorization codes redirected after user authentication. PKCE (RFC 7636) is the complete defense: the intercepted code is useless without the code verifier that only the legitimate app generated at the start of the flow.

When an ID token or access token is included in a URL fragment or query parameter, subsequent navigations from that page include the URL in the Referer header, potentially leaking the token to third-party analytics scripts or CDN providers. Always use the authorization code flow with back-channel token delivery to avoid tokens appearing in URLs.

When a client supports multiple OAuth providers, mix-up attacks trick the client into sending an authorization code obtained from Provider A to Provider B's token endpoint. The client must validate the "iss" claim in ID tokens and bind the callback to the specific provider that initiated the flow using the state parameter or JARM (JWT-Secured Authorization Response Mode).

Server-side request forgery (SSRF) attacks target OAuth implementations that make server-side HTTP requests to the redirect_uri. If the authorization server fetches the redirect_uri to verify it, an attacker supplies an internal IP address (e.g., http://169.254.169.254/latest/meta-data/) to access cloud instance metadata or internal services. Strict allowlist-based redirect_uri validation prevents this.

Many applications use the email claim from an OIDC ID token to link accounts across providers. If an attacker controls an email address that matches a victim's account at another provider, they can register with a different provider using that email and gain access to the victim's account. Defense: link accounts by (iss, sub) pair only, never by email alone.

JWT algorithm confusion attacks exploit implementations that trust the "alg" header to select the verification algorithm. Attack: change "alg" from "RS256" to "HS256" and sign the token with the server's public key as the HMAC secret (since the public key is public). Defense: always specify the expected algorithm explicitly in the verification code, never trust the token header's alg claim.

Attackers register malicious OAuth clients with legitimate-looking names and logos, then send phishing links to targets. The victim sees a genuine OAuth consent screen (hosted by Google, Microsoft, etc.) for a malicious application and grants access. Defense: verify client_id corresponds to the expected application; Google and Microsoft provide client verification programs for legitimate apps.

Scope escalation occurs when a client obtains tokens with broader permissions than what the user authorized. Implementation flaws that skip scope validation on the token endpoint, cache tokens with merged scopes across different requests, or fail to validate that the scope in the issued token does not exceed the authorized scope can all lead to privilege escalation via OAuth.

Defend OAuth implementations by: using exact-match redirect_uri validation, requiring PKCE for all public clients, validating the state parameter for CSRF protection, binding ID tokens by (iss, sub) not email, specifying expected JWT algorithms explicitly, requesting minimal scopes, using short-lived access tokens with refresh token rotation, and auditing consent screen appearance for brand impersonation risk.

An OAuth authorization server accepts any redirect_uri that begins with "https://app.example.com". What attack does this enable?

Key OAuth attacks: open redirect via lax redirect_uri validation (use exact match), CSRF via missing state parameter, code interception on mobile (mitigated by PKCE), token leakage in URLs, mix-up in multi-provider setups (validate iss), SSRF via server-fetched redirect_uri, email claim collision (use iss+sub), JWT algorithm confusion (fix expected alg), and phishing via fake consent screens.