Token theft and authorization bypass expose customer data and enable account takeover across web applications and APIs. These attacks succeed when applications fail to properly validate authorization flows or store authentication tokens securely.OAuth 2.0 is an authorization framework that enables applications to obtain limited access to user accounts. The protocol delegates user authentication to the service that hosts the user account and authorizes third-party applications to access that account without exposing credentials.OpenID Connect (OIDC) builds an identity layer on top of OAuth 2.0. While OAuth handles authorization (what resources can be accessed), OIDC adds authentication (who the user is) by introducing standardized identity tokens.The key distinction: OAuth answers "What can this application do?" while OIDC answers "Who is this user?". Applications requesting user data need OAuth scopes. Applications needing to identify users require OIDC identity tokens containing claims about the authenticated user.Both protocols rely on tokens rather than passwords for access control. OAuth uses access tokens for resource authorization, while OIDC adds ID tokens for user identity.
Authorization code interception exploits the code exchange step in flows without PKCE protection. Attackers monitor network traffic or deploy malicious applications to capture authorization codes, then exchange them for valid access tokens before legitimate clients complete the flow. The operational consequence: compromised codes grant full account access within the requested scope permissions. PKCE prevents this attack by requiring cryptographic proof that the client initiating the flow matches the client exchanging the code. (RFC 7636)Token Injection Attacks
Token injection attacks target insufficient redirect URI validation in authorization servers. Attackers register malicious redirect URIs or exploit wildcard URI patterns to receive authorization codes or tokens intended for legitimate applications. The attack succeeds when authorization servers accept overly broad redirect URI patterns or fail to validate exact URI matches. The business consequence: unauthorized applications gain access to user accounts and data through hijacked authorization flows. (RFC 9700)Cross-Site Request Forgery (CSRF) on OAuth Endpoints
CSRF attacks force users to unknowingly authorize malicious applications through their authenticated browser sessions. Attackers craft requests that trigger OAuth authorization flows using the victim's existing login state, granting access to attacker-controlled applications without user knowledge. The state parameter provides CSRF protection by including unguessable values that clients verify upon callback. Notably, RFC 9700 establishes that PKCE also provides CSRF protection for public clients, making it the preferred defense for those client types. (RFC 9700)Open Redirect Vulnerabilities
Open redirects in OAuth endpoints enable phishing campaigns and token theft when authorization servers fail to validate redirect URIs against allowlists. Attackers redirect users to malicious sites after authentication, harvesting credentials or authorization codes intended for legitimate applications. These attacks appear legitimate to users who see valid authorization server domains in their browser during the initial redirect. (RFC 9700)Insufficient Scope Validation
Scope validation failures allow privilege escalation beyond intended permissions when applications request excessive scopes or authorization servers fail to enforce scope restrictions. Users may inadvertently grant broader access than intended, enabling applications to access sensitive data beyond their stated functionality. Regular scope audits identify applications with excessive permissions. (RFC 6749)JWT Token Manipulation
JWT manipulation targets OIDC implementations with weak signature validation or key management. Attackers modify ID token claims to impersonate users or escalate privileges when applications fail to verify JWT signatures against trusted public keys. The attack succeeds when applications trust token contents without cryptographic verification. (RFC 7519; OpenID Connect Core 1.0)Refresh Token Theft
Refresh token compromise provides persistent access even after access tokens expire. These long-lived tokens stored insecurely in client applications or transmitted without proper protection enable long-term account compromise. Rotating refresh tokens and secure storage mechanisms limit this exposure window. (RFC 9700)
Core Capabilities
OAuth 2.0 defines four grant types, though modern implementations focus on two secure flows:Authorization Code Flow with PKCE serves as the primary mechanism for web and mobile applications. The client redirects users to the authorization server, receives an authorization code, then exchanges that code plus a cryptographic verifier for tokens. PKCE (Proof Key for Code Exchange) prevents authorization code interception attacks by requiring clients to generate a code verifier and challenge. (RFC 7636; RFC 9700)Client Credentials Flow handles server-to-server authentication where no user interaction occurs. The client authenticates directly with the authorization server using client ID and secret to obtain access tokens. (RFC 6749)The Implicit Flow has been deprecated due to security vulnerabilities. This flow returned tokens directly in URL fragments, creating exposure risks that PKCE-enabled authorization code flow eliminates. RFC 9700 (BCP 240) formally recommends against its use. (RFC 9700)Refresh Flow extends token lifetime without user re-authentication. When access tokens expire, clients can exchange valid refresh tokens for new access tokens, maintaining session continuity. (RFC 6749)OIDC adds standardized identity capabilities through ID tokens formatted as JSON Web Tokens (JWTs). These tokens contain claims about the authenticated user, token issuer, audience, and expiration times. OIDC also provides UserInfo endpoints for retrieving additional user profile data. (OpenID Connect Core 1.0; RFC 7519)Scopes define the granular permissions requested by client applications. OAuth scopes likeread:profile or write:calendar specify resource access levels, while OIDC scopes like openid, profile, and email determine which identity claims are included in ID tokens. (RFC 6749; OpenID Connect Core 1.0)Attack Surfaces and Threat Vectors
Authorization Code InterceptionAuthorization code interception exploits the code exchange step in flows without PKCE protection. Attackers monitor network traffic or deploy malicious applications to capture authorization codes, then exchange them for valid access tokens before legitimate clients complete the flow. The operational consequence: compromised codes grant full account access within the requested scope permissions. PKCE prevents this attack by requiring cryptographic proof that the client initiating the flow matches the client exchanging the code. (RFC 7636)Token Injection Attacks
Token injection attacks target insufficient redirect URI validation in authorization servers. Attackers register malicious redirect URIs or exploit wildcard URI patterns to receive authorization codes or tokens intended for legitimate applications. The attack succeeds when authorization servers accept overly broad redirect URI patterns or fail to validate exact URI matches. The business consequence: unauthorized applications gain access to user accounts and data through hijacked authorization flows. (RFC 9700)Cross-Site Request Forgery (CSRF) on OAuth Endpoints
CSRF attacks force users to unknowingly authorize malicious applications through their authenticated browser sessions. Attackers craft requests that trigger OAuth authorization flows using the victim's existing login state, granting access to attacker-controlled applications without user knowledge. The state parameter provides CSRF protection by including unguessable values that clients verify upon callback. Notably, RFC 9700 establishes that PKCE also provides CSRF protection for public clients, making it the preferred defense for those client types. (RFC 9700)Open Redirect Vulnerabilities
Open redirects in OAuth endpoints enable phishing campaigns and token theft when authorization servers fail to validate redirect URIs against allowlists. Attackers redirect users to malicious sites after authentication, harvesting credentials or authorization codes intended for legitimate applications. These attacks appear legitimate to users who see valid authorization server domains in their browser during the initial redirect. (RFC 9700)Insufficient Scope Validation
Scope validation failures allow privilege escalation beyond intended permissions when applications request excessive scopes or authorization servers fail to enforce scope restrictions. Users may inadvertently grant broader access than intended, enabling applications to access sensitive data beyond their stated functionality. Regular scope audits identify applications with excessive permissions. (RFC 6749)JWT Token Manipulation
JWT manipulation targets OIDC implementations with weak signature validation or key management. Attackers modify ID token claims to impersonate users or escalate privileges when applications fail to verify JWT signatures against trusted public keys. The attack succeeds when applications trust token contents without cryptographic verification. (RFC 7519; OpenID Connect Core 1.0)Refresh Token Theft
Refresh token compromise provides persistent access even after access tokens expire. These long-lived tokens stored insecurely in client applications or transmitted without proper protection enable long-term account compromise. Rotating refresh tokens and secure storage mechanisms limit this exposure window. (RFC 9700)
Getting Started Checklist
Implement Authorization Code Flow with PKCE for all client types. Web applications, single-page applications, and mobile apps should use authorization code flow with PKCE rather than deprecated implicit flows. Generate cryptographically random code verifiers and use the S256 challenge method. (RFC 7636; RFC 9700)Enforce strict redirect URI validation. Register exact redirect URIs for each client application and reject requests with unregistered URIs. Avoid wildcard patterns or partial matching that attackers can exploit for token injection. (RFC 9700)Configure minimal necessary scopes per application. Grant applications only the specific permissions required for their functionality rather than broad administrative scopes. Regularly audit scope assignments and revoke unused permissions. (RFC 6749; RFC 9700)Implement state parameter validation for CSRF protection. Generate unguessable state values for each authorization request and verify them upon callback to prevent cross-site request forgery. For public clients, PKCE provides equivalent CSRF protection and should be used alongside or in place of the state parameter. (RFC 9700)Set appropriate token expiration policies. Access tokens should have short lifetimes — on the order of hours or less — while refresh tokens can have longer lifetimes paired with rotation. Shorter access token lifetimes reduce the exposure window if a token is compromised. (RFC 9700)Validate JWT signatures and claims in OIDC implementations. Verify ID token signatures against the authorization server's public keys and validate the issuer (iss), audience (aud), and expiration (exp) claims. Reject tokens with modified or expired claims. (RFC 7519; OpenID Connect Core 1.0)Secure token storage in client applications. Store tokens in secure storage mechanisms appropriate for the client type — HTTP-only cookies for web apps, secure keychains for mobile apps. Avoid storing sensitive tokens in browser local storage. (RFC 9700)Monitor for suspicious authorization patterns. Log authorization requests and token exchanges to detect unusual patterns like repeated failed attempts or requests from unexpected locations. Alert on authorization requests for high-privilege scopes. (MITRE ATT&CK T1528)
