OAuth Threat Model — CSRF, Token Leakage, Confused Deputy & Common Pitfalls

Overview

OAuth security is a threat model, not a grant-type checklist. Classic failures: login CSRF (missing state), token leakage (query logs, XSS, Referer), authorization code interception (mitigated by PKCE), confused deputy (token audience / redirect URI mix-ups), and refresh theft.

This page maps attacks → controls across the cluster rather than treating OAuth as a menu of grants.

Attack → primary control

What fails if you choose wrong

• "We use OAuth so we're secure" with implicit + localStorage.
• CSRF token on forms but no OAuth state.
• Validating JWT signature only — skipping aud / iss.
• One redirect URI allowlisting via naive substring match.

CSRF on the OAuth redirect

1. Attacker runs the authorize flow on the victim app with their own account and stops before the client redeems the code, keeping the callback URL (code=attacker_code).
2. Attacker makes the victim's browser load that callback URL (link, img tag, or auto-submitting form).
3. If the client does not check state, it redeems the attacker code and the victim is signed in as the attacker.

Control: Generate state in the client session before redirect; verify exact match on callback. Prefer ≥128 bits of entropy. For OIDC, also verify nonce in the id_token.

flowchart TB
  a["Attacker Ready"]
  v["Victim browser Ready"]
  c["Client app Ready"]
  as["Auth Server Ready"]
  fail["Failure path - client redeems the attacker code Ready"]
  a -->|Step 1 Attacker logs in with an own account| as
  as -->|Step 2 Callback URL with the attacker code - attacker stops here| a
  a -->|Step 3 Lure the victim to the client callback with that code| v
  v -->|Step 4 GET /callback?code=attacker_code| c
  c -->|Step 5 state missing or mismatched - reject| v
  c -->|Failure path - client redeems the attacker code| fail
  c -->|Victim is signed in as the attacker - data lands in the attacker account| v

Step 5 rejects a missing or mismatched state with a reply to the victim browser. That check is not a labeled self-loop on the client.

Token leakage channels

• URL query (never put tokens in query; codes still leak via logs/Referer — keep codes short-lived and one-time).
• Browser history / analytics scripts reading locations.
• Server access logs on redirect_uri.
• XSS reading memory / localStorage.
• Mobile OS URL handlers.
• Intermediate proxies decrypting TLS (corporate MITM) — assume possible for browser traffic.

Confused deputy (classic OAuth)

A client with an access token for API A is tricked into using it against API B, or an AS issues tokens without binding to the intended resource.

Controls: Resource Indicators (RFC 8707), strict aud, per-API tokens, avoid "god scope", sender-constrained tokens (DPoP / mTLS).

A decision node fans reject vs accept. Do not hang two labeled outcomes off a self-loop.

Authorization code pitfalls

• Reuse of codes (must be one-time).
• Long code lifetime.
• Accepting a code at the token endpoint with a mismatched redirect_uri.
• Public client without PKCE.

Mix-up attacks (brief)

When multiple authorization servers exist, a client might send a code to the wrong token endpoint or accept tokens from an unexpected issuer. Respond with issuer identification in responses and pre-registered AS metadata — never trust attacker-supplied JWKS URLs.

Sandbox: state + redirect allowlist (Python)

Exact callback match, then exact state. Forged state and evil.example both fail closed.

Press Run. Snippets must be self-contained — no network, files, or native modules.

Sandbox: audience enforce (TypeScript)

The brake on confused deputy. Array or string aud both work; missing expected audience throws.

Press Run. Snippets must be self-contained — no network, files, or native modules.

Pitfalls

Interview Q&A

Go Deeper

• RFC 9700 — OAuth 2.0 Security BCP
• RFC 6819 — OAuth 2.0 Threat Model
• RFC 8707 — Resource Indicators
• OAuth 2.1 draft
• OWASP Cheat Sheet Series
• Auth0 — Attack Protection
• oauth.net — Security BCP
• Aaron Parecki — OAuth 2.1 talk