Common OAuth Vulnerabilities

Analogy categoryAnalogies

Why OAuth Implementations Get Broken

OAuth 2.0 is a framework, not a single protocol, and most of its real-world vulnerabilities come from optional pieces being implemented incorrectly rather than from flaws in the specification itself. Attackers rarely break the cryptography; they exploit missing validation steps such as an unchecked redirect_uri, a reused state value, or an authorization code that can be replayed. Because OAuth touches identity, session management, and third-party trust boundaries at once, a single missing check can cascade into full account takeover.

🏏

Cricket analogy: Like a fielding side that nails its bowling plan but forgets to check the boundary rope markings, a team can get the OAuth flow's core logic right and still concede runs through an unchecked edge case like redirect validation.

Authorization Code Interception and Replay

The authorization code grant hands a short-lived code to the client, which the client then exchanges for tokens at the token endpoint. If that code is intercepted, for example via a malicious app registering the same custom URI scheme on a mobile device, or via referrer headers leaking it to a third-party site, an attacker can attempt to redeem it themselves. Without PKCE or a client_secret binding the exchange to the original requester, the authorization server has no way to distinguish the legitimate client from the attacker, and the stolen code becomes a live login.

🏏

Cricket analogy: A run-out chance where the ball is intercepted mid-throw between wicketkeeper and bowler is exactly like an authorization code intercepted mid-flight before it reaches the legitimate client's token exchange.

Token Leakage via Referrer Headers and Browser History

Implicit grant flows and misconfigured redirect handling historically leaked access tokens straight into the URL fragment or query string, where they end up in browser history, server access logs, and Referer headers sent to any third-party resource loaded on the redirect page. A tracking pixel or analytics script on the client's landing page can silently exfiltrate a token that was never meant to leave the browser tab. This is one of the core reasons the implicit grant is now deprecated in favor of authorization code plus PKCE, which never exposes a long-lived token in a URL.

🏏

Cricket analogy: Leaving your DRS review strategy visible on a broadcast feed that opposition analysts can rewind and study is like a token leaking into browser history where it lingers, visible long after the moment passed.

Cross-Site Request Forgery on the Authorization Endpoint

Without a state parameter tying the authorization request to the user's browser session, an attacker can trick a victim into completing an OAuth flow using the attacker's own account, then have the victim unknowingly link their identity or upload data to the attacker's account, an attack known as login CSRF. This is distinct from redirect abuse: the attacker isn't stealing a token, they're forcing the victim's authenticated session to bind to attacker-controlled resources, which can be just as damaging in social login and account-linking scenarios.

🏏

Cricket analogy: It's like an umpire being tricked into crediting a boundary to the wrong batsman's scorecard because nobody checked which end the shot was hit from; login CSRF binds the victim's session to the wrong account the same way.

http

POST /token HTTP/1.1
Host: authz.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https://client.example.com/cb
&client_id=s6BhdRkqt3
&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

# Vulnerable server: accepts the code without verifying code_verifier
# against the code_challenge stored at /authorize time, so any party
# holding an intercepted `code` can complete the exchange.

Never assume the implicit grant, response_type=token, is safe for a modern single-page app. It is formally deprecated in OAuth 2.1 precisely because it hands out access tokens in URL fragments with no code-exchange step to bind them to the legitimate client.

Most OAuth breaches exploit missing optional validations, not the core specification.
Authorization codes without PKCE or client authentication can be intercepted and replayed.
URL fragments and query strings leak tokens into browser history, server logs, and referrer headers.
Login CSRF binds a victim's session to an attacker's account when state is missing or not validated.
The implicit grant is deprecated because it exposes tokens directly in redirect URLs.
Defense requires layering PKCE, state, strict redirect_uri matching, and short token lifetimes together.