How to Find OAuth Vulnerabilities That Lead to Account Takeover

How to Find OAuth Vulnerabilities That Lead to Account Takeover

OAuth bugs are rarely found by changing one parameter at random. The useful approach is to model the full authorization flow and identify where the client, authorization server, and browser disagree about identity or destination.

Only test accounts and OAuth clients you are authorized to use. Never capture a real user's authorization code or access token.

First, record a clean flow

Proxy a normal login and label these values:

• authorization endpoint and token endpoint
• client_id
• exact redirect_uri
• state, nonce, and PKCE parameters
• requested scopes
• response type and response mode
• identity claims returned to the client

Repeat with two test accounts. This makes account-linking mistakes visible.

Test redirect URI validation

The authorization server should compare a registered redirect URI exactly. Test controlled variations one at a time:

• alternate subdomains and ports
• path traversal and duplicated slashes
• URL-encoded separators
• appended query strings or fragments
• user-info syntax such as trusted.example@attacker.example
• duplicate redirect_uri parameters

A bypass matters when a code or token reaches a domain you control. Stop with your own test account and redact the credential.

Verify state, nonce, and PKCE

state should be unpredictable, bound to the browser session, and checked once. Remove it, reuse it, and swap values between your two sessions. Missing validation can create login CSRF, where a victim is logged into the attacker's account and later enters sensitive information there.

OpenID Connect clients should validate nonce, issuer, audience, signature, and token lifetime. Native and public clients should use PKCE. Try exchanging a code with a verifier from the wrong session; the request must fail.

Look closely at account linking

Many high-impact OAuth findings live after authentication. Ask:

1. Can a logged-in user attach a social identity without reauthentication?
2. Does the application trust email alone?
3. What happens if the provider returns an unverified email?
4. Can two providers claim the same address?
5. Can an attacker pre-link their provider identity to a victim's pending account?

Use two accounts to show the identity confusion without affecting anyone else.

Scope and token handling

Request fewer and then more scopes. The server should reject unregistered or unauthorized scopes. Inspect browser history, referrers, analytics requests, logs, and front-end storage for code or token leakage. Authorization codes should be short-lived, single-use, and bound to the same client and redirect URI at the token endpoint.

Reporting a strong OAuth bug

Show a complete sequence: attacker setup, victim interaction, callback behavior, identity selected, and final security impact. Explain which party must fix the issue. Include sanitized requests and prove control using two test accounts.

Recommended fixes

• Exact-match registered redirect URIs.
• Session-bound, single-use state.
• PKCE for public clients and preferably all authorization-code flows.
• Strict issuer, audience, nonce, and signature validation.
• Reauthentication before linking identities.
• Never treat an unverified email as proof of account ownership.
• Keep tokens out of URLs, logs, and long-lived browser storage.

OAuth is secure when every participant validates the same transaction. Account takeover appears in the gaps between those validations.

Original Bugflare guide informed by PortSwigger's OAuth security material and current OAuth security best practices.