OAuth 2.0 Security: The Authorization Vulnerabilities Developers Miss

OAuth 2.0 is the authorization framework behind nearly every modern web application’s “Sign in with Google/GitHub/Microsoft” button. It’s also the source of a disproportionate number of account takeover vulnerabilities — not because the spec is broken, but because the spec is complex, optional security features are easy to skip, and the failure modes are non-obvious.

This guide covers the six OAuth 2.0 vulnerabilities that appear most frequently in security assessments, with concrete code showing the problem and the fix.

1. Missing State Parameter (CSRF)

The vulnerability: The state parameter is OAuth’s CSRF token. It’s generated by the client, sent to the authorization server, and must be verified on the callback. Without it, an attacker can perform a CSRF attack that silently links the victim’s account to an attacker-controlled OAuth account.

Attack scenario: attacker initiates an OAuth flow, captures the authorization URL before completing it, tricks the victim into visiting that URL. If the victim is logged in, their account gets linked to the attacker’s identity provider account.

Vulnerable:

// No state parameter
app.get('/auth/login', (req, res) => {
  const authUrl = `https://provider.com/oauth/authorize?` +
    `client_id=${CLIENT_ID}&` +
    `redirect_uri=${REDIRECT_URI}&` +
    `response_type=code&` +
    `scope=openid profile`;
  res.redirect(authUrl);
});

Fixed:

import crypto from 'crypto';

app.get('/auth/login', (req, res) => {
  const state = crypto.randomBytes(32).toString('hex');
  req.session.oauthState = state;  // store in server-side session

  const authUrl = `https://provider.com/oauth/authorize?` +
    `client_id=${CLIENT_ID}&` +
    `redirect_uri=${REDIRECT_URI}&` +
    `response_type=code&` +
    `scope=openid profile&` +
    `state=${state}`;
  res.redirect(authUrl);
});

app.get('/auth/callback', (req, res) => {
  const { code, state } = req.query;
  if (!state || state !== req.session.oauthState) {
    return res.status(403).send('State mismatch  --  possible CSRF');
  }
  // proceed with token exchange
});

2. Open Redirect in redirect_uri

The vulnerability: If your callback endpoint accepts dynamic path parameters and redirects to them, an attacker can craft an authorization URL with a redirect that includes a malicious destination. After the auth code is issued, the browser gets sent to the attacker’s site with the code in the URL.

Many providers validate only the registered base domain, not the full path. An open redirect on any page under your domain can be used as the redirect target.

Check for:

• Query parameters passed through to a redirect: ?next=https://evil.com
• Path traversal in callback URLs: https://yourapp.com/callback/../redirect?url=https://evil.com

Fix:

• Register exact redirect URIs with the provider, not just domains
• Validate the incoming redirect_uri against a strict allowlist before proceeding
• Audit all endpoints under your domain for open redirect vulnerabilities — they become OAuth attack surfaces

3. Implicit Flow Token Leakage

The vulnerability: The implicit flow (response_type=token) returns an access token directly in the URL fragment: https://yourapp.com/callback#access_token=.... Fragments appear in browser history, server logs (if any redirect occurs), and Referer headers when navigating from the callback page.

The implicit flow is deprecated in OAuth 2.1. There’s no reason to use it in new applications.

What to use instead:

Authorization Code Flow with PKCE (see below). If you’re migrating an existing SPA from implicit flow:

// Old (implicit flow - don't use):
// response_type=token

// New (authorization code + PKCE):
// response_type=code
// code_challenge=<challenge>
// code_challenge_method=S256

The code is exchanged for a token server-side (or via a PKCE-protected token request), never appearing in the URL fragment.

4. Missing PKCE for Public Clients

The vulnerability: PKCE (Proof Key for Code Exchange) prevents authorization code interception attacks. Without it, if an attacker can observe the authorization code (via a malicious app, browser extension, or log access), they can exchange it for tokens before your legitimate client does.

PKCE is required for all public clients (SPAs, native mobile apps, desktop apps) that cannot securely store a client secret.

Implementation:

import hashlib
import base64
import os

def generate_pkce():
    code_verifier = base64.urlsafe_b64encode(os.urandom(32)).rstrip(b'=').decode()
    code_challenge = base64.urlsafe_b64encode(
        hashlib.sha256(code_verifier.encode()).digest()
    ).rstrip(b'=').decode()
    return code_verifier, code_challenge

# In the auth request:
code_verifier, code_challenge = generate_pkce()
session['code_verifier'] = code_verifier  # store for token exchange

auth_url = (
    f"https://provider.com/oauth/authorize"
    f"?client_id={CLIENT_ID}"
    f"&redirect_uri={REDIRECT_URI}"
    f"&response_type=code"
    f"&code_challenge={code_challenge}"
    f"&code_challenge_method=S256"
    f"&state={state}"
)

# In the token exchange:
token_response = requests.post('https://provider.com/oauth/token', data={
    'grant_type': 'authorization_code',
    'code': auth_code,
    'redirect_uri': REDIRECT_URI,
    'client_id': CLIENT_ID,
    'code_verifier': session.pop('code_verifier'),
})

5. Access Token Storage in localStorage

The vulnerability: Storing access tokens in localStorage or sessionStorage makes them accessible to any JavaScript running on your page — including injected scripts from XSS. An XSS vulnerability anywhere in your application can silently exfiltrate every stored token.

The tradeoff: httpOnly cookies can’t be read by JavaScript (XSS can’t steal them directly), but they’re vulnerable to CSRF. The combination of httpOnly + SameSite=Strict cookies resolves both.

For SPAs: Use a token handler pattern — the authorization code exchange and token storage happen in a thin backend service that sets httpOnly cookies. The SPA never touches tokens directly. Libraries like @auth0/auth0-react implement this by default if you configure it correctly.

// Don't do this:
localStorage.setItem('access_token', token);

// Instead: let the backend handle token storage
// and use httpOnly cookies for the session

6. Scope Creep and Over-Permissioned Tokens

The vulnerability: Requesting more OAuth scopes than your application actually needs. If your token is compromised, the attacker gets access to everything you requested. Common examples: requesting https://mail.google.com/ scope for an app that only needs to read the user’s name.

The pattern: Request the minimum scope required at each point of use. Many providers support incremental authorization — request additional scopes lazily when the user actually reaches a feature that needs them, rather than requesting everything upfront.

// Minimal initial scope (login only)
const loginScopes = 'openid profile email';

// Requested only when user accesses calendar feature
const calendarScopes = 'openid profile https://www.googleapis.com/auth/calendar.readonly';

// Check if current token has required scope before requesting new auth
function hasScope(token, scope) {
  const tokenScopes = parseJwt(token).scope?.split(' ') ?? [];
  return tokenScopes.includes(scope);
}

Summary: Implementation Checklist

Control	Required?	Notes
state parameter with CSRF validation	Yes, always	Use cryptographically random value stored in server session
PKCE	Yes, for public clients	Use S256 method
Exact redirect URI registration	Yes	Never register wildcards or domain-only
Avoid implicit flow	Yes	Use authorization code + PKCE instead
httpOnly cookies for token storage	Preferred	Avoids XSS token theft
Minimal scope	Yes	Request only what you need
Token rotation on refresh	Yes	Prevents long-lived token reuse

OAuth 2.0 is well-designed when implemented correctly. Most vulnerabilities aren’t spec failures — they’re developers skipping security parameters that look optional in tutorials but are essential in production.