OAuth Vulnerabilities: When Authentication Goes Wrong

OAuth 2.0 is the dominant authorization framework on the modern web, powering "Sign in with Google," "Login with Facebook," and countless third-party integrations. Its flexibility is both its strength and its weakness: multiple grant types and implementation choices each introduce opportunities for security mistakes. In my testing experience, OAuth vulnerabilities frequently lead to full account takeover or privilege escalation -- among the highest-impact penetration test findings.

OAuth 2.0 Flow Overview

The Authorization Code flow works as follows: the client redirects the user to the authorization server with client_id, redirect_uri, scope, and state. After authentication, the server redirects back with an authorization code, which the client exchanges for an access token. Each step presents attack opportunities.

The Implicit flow returns the access token directly in the URL fragment, exposing it in browser history, referrer headers, and server logs. The OAuth Security Best Current Practice (RFC 9700) now explicitly recommends against this flow in favor of Authorization Code with PKCE.

Open Redirect Exploitation

The redirect_uri is the most critical OAuth attack vector. If an attacker can influence where the authorization code is sent, they steal it. Bypass techniques include:

• Path manipulation - Appending /callback/../attacker-page when only the base domain is validated.
• URL parsing differentials - Backslashes, URL-encoded characters (%2F, %23), or unicode causing the validator and browser to interpret the URL differently.
• Chaining open redirects - Find an open redirect on the legitimate domain (e.g., /login?next=https://attacker.com) and use it as redirect_uri. The server validates the domain, but the app forwards the code to the attacker.
• Subdomain takeover - If validation allows *.example.com and a subdomain has dangling DNS, the attacker claims it to receive authorization codes.

CSRF via Missing State Parameter

The state parameter acts as a CSRF token. Without it, an attacker initiates an OAuth flow with their own account and tricks the victim into completing it, linking the attacker's third-party identity to the victim's account for persistent access. Test by removing state entirely, replacing it with an empty value, or reusing state from a different session -- and checking whether the callback still succeeds.

Token Leakage and Insecure Storage

Tokens leak through Referer headers when the callback page loads external resources, browser history storing codes from query parameters, server logs recording full URLs, and users copying callback URLs into support tickets. These risks are amplified with the Implicit flow where tokens appear in URL fragments.

Client-side storage determines XSS exposure. Tokens in localStorage are accessible to any JavaScript including XSS payloads. Use httpOnly, Secure, SameSite cookies for browsers, and platform keychains (iOS Keychain, Android Keystore) for mobile.

Authorization Code Flow Attacks

• Code reuse - Codes must be single-use per the specification. Capture a valid code and exchange it multiple times at the token endpoint. A robust server should revoke all tokens issued from a reused code.
• redirect_uri bypass at token exchange - Some servers validate redirect_uri during authorization but not during token exchange, allowing codes obtained via manipulated URIs to be exchanged with the legitimate URI.
• Missing PKCE - Without PKCE, intercepted codes (via malicious apps or compromised redirects) can be exchanged for tokens. Check for code_challenge in authorization requests and code_verifier in token requests.
• Client secret exposure - Public clients cannot securely store secrets. Extract embedded secrets through app reversing to exchange intercepted codes.

Real-World Impact

These are not theoretical risks. Account takeover through redirect_uri manipulation has affected major platforms. CSRF attacks have allowed linking malicious accounts to victim profiles for persistent access. Token leakage through misconfigured logging has exposed user data at scale. These appear regularly in bug bounty programs and penetration tests.

Testing Methodology

1. Map the implementation - Identify grant types, OAuth provider, scopes, and token storage. Intercept the full flow in Burp Suite.
2. Test redirect_uri - Try path traversal, parameter pollution, encoding tricks, and open redirect chaining.
3. Verify state handling - Remove state, use empty and cross-session values, confirm rejection.
4. Test code handling - Replay codes, exchange from manipulated redirect_uris, verify short expiration.
5. Check PKCE - Submit token exchange without code_verifier to test enforcement.
6. Analyze tokens - Check storage, expiration, revocation, and refresh token rotation.
7. Test scope escalation - Request admin scopes beyond normal usage.

Tools

• Burp Suite - Intercept and modify OAuth flows. Logger++ tracks redirect chains. Repeater enables precise parameter manipulation.
• EsPReSSO - Burp extension for SSO protocol testing including OAuth and OpenID Connect.
• Browser DevTools - Network tab for redirect chains, Application tab for token storage, headers for Referer leakage.
• Postman - Construct token exchange requests, test code reuse, and experiment with parameter combinations.

Remediation

Use Authorization Code with PKCE for all client types. Validate redirect_uri with exact string matching, not patterns. Always validate a cryptographically random state parameter. Make authorization codes single-use with short expiration (under 10 minutes), bound to the requesting client and redirect_uri. Store tokens in httpOnly cookies or platform-secure storage, never localStorage. Rotate refresh tokens on use and set reasonable access token lifetimes. Log all OAuth events for security monitoring, including failed validations and token exchange anomalies.