OAuth 2.0 Security: Common Misconfigurations and How to Prevent Them

The redirect_uri is where the authorization server sends the authorization code after user approval. If an attacker can control the redirect_uri, they receive the code: which they can exchange for an access token.

Vulnerable: wildcard or prefix matching:

# Authorization server accepts any URI starting with the app's domain
Allowed: https://app.example.com/*

# Attacker crafts:
https://authserver.com/authorize?
  client_id=myapp&
  redirect_uri=https://app.example.com.attacker.com/callback&
  ...

The attacker registers app.example.com.attacker.com: the wildcard match passes, and the code is delivered to the attacker's server.

Vulnerable: open redirect on the legitimate domain:

# Application has an open redirect at /redirect?url=
https://app.example.com/redirect?url=https://attacker.com

# Attacker uses:
redirect_uri=https://app.example.com/redirect?url=https://attacker.com/steal

Secure: exact URI matching only:

# Authorization server should validate exact match, not prefix or pattern match
ALLOWED_REDIRECT_URIS = {
    'myapp-client-id': [
        'https://app.example.com/oauth/callback',
        'https://staging.example.com/oauth/callback',
    ]
}

def validate_redirect_uri(client_id: str, redirect_uri: str) -> bool:
    allowed = ALLOWED_REDIRECT_URIS.get(client_id, [])
    return redirect_uri in allowed  # Exact string match, no wildcards

Register only specific, exact URIs: never register https://app.example.com/* or https://app.example.com. Every legitimate redirect path should be registered individually.

The state parameter prevents CSRF attacks where an attacker tricks a victim's browser into completing an OAuth flow and binding the attacker's account credentials to the victim's session.

How the CSRF attack works:

1. Attacker initiates an OAuth flow with their own client, gets an authorization URL
2. Before completing the flow themselves, they trick the victim into visiting that URL
3. Victim clicks "Allow": their browser sends the authorization code to the redirect_uri
4. Victim's session is now linked to the attacker's OAuth credentials
5. Attacker can now access victim's account by completing the flow later

Vulnerable: no state parameter:

https://authserver.com/authorize?client_id=app&redirect_uri=...&response_type=code
# No state parameter: the authorization response cannot be tied to the initiating request

Secure: cryptographically random state, validated on return:

import secrets
import hashlib

def initiate_oauth_flow(request):
    # Generate a cryptographically random state value
    state = secrets.token_urlsafe(32)
    
    # Store in server-side session (not cookie: prevent fixation)
    request.session['oauth_state'] = state
    request.session['oauth_state_created'] = time.time()
    
    # Include in authorization URL
    auth_url = f"{AUTH_URL}?client_id={CLIENT_ID}&state={state}&..."
    return redirect(auth_url)

def handle_oauth_callback(request):
    received_state = request.GET.get('state')
    stored_state = request.session.pop('oauth_state', None)
    state_created = request.session.pop('oauth_state_created', 0)
    
    # Validate: state must match, must be recent, must be present
    if not received_state or not stored_state:
        raise AuthError('Missing state parameter')
    if not secrets.compare_digest(received_state, stored_state):
        raise AuthError('State parameter mismatch: possible CSRF attack')
    if time.time() - state_created > 300:  # 5-minute expiry
        raise AuthError('State expired')
    
    # State validated: proceed with code exchange
    code = request.GET.get('code')
    exchange_code_for_token(code)

Single-page applications (SPAs) and mobile apps are public clients: they cannot securely store a client secret because any user can inspect the app's code or binary and extract it. Sending a client_secret from a SPA is the same as having no secret at all.

PKCE (Proof Key for Code Exchange, RFC 7636) solves this by having the client generate a random verifier, hash it as a challenge, send the challenge with the authorization request, then send the original verifier with the token request: the server verifies the hash matches.

PKCE implementation (JavaScript/TypeScript):

async function initiateOAuthWithPKCE(): Promise<void> {
  // Generate a random code verifier (43-128 characters)
  const codeVerifier = generateCodeVerifier();
  
  // Hash it using SHA-256 to create the code challenge
  const codeChallenge = await generateCodeChallenge(codeVerifier);
  
  // Store the verifier securely (sessionStorage, not localStorage)
  sessionStorage.setItem('code_verifier', codeVerifier);
  
  // Redirect to authorization server with challenge
  const params = new URLSearchParams({
    client_id: 'my-spa-client',
    response_type: 'code',
    redirect_uri: 'https://app.example.com/callback',
    scope: 'openid profile',
    state: generateState(),
    code_challenge: codeChallenge,
    code_challenge_method: 'S256',
  });
  window.location.href = `https://auth.example.com/authorize?${params}`;
}

function generateCodeVerifier(): string {
  const array = new Uint8Array(32);
  crypto.getRandomValues(array);
  return base64UrlEncode(array);
}

async function generateCodeChallenge(verifier: string): Promise<string> {
  const encoder = new TextEncoder();
  const data = encoder.encode(verifier);
  const digest = await crypto.subtle.digest('SHA-256', data);
  return base64UrlEncode(new Uint8Array(digest));
}

// On callback: exchange code using the verifier
async function handleCallback(code: string): Promise<void> {
  const codeVerifier = sessionStorage.getItem('code_verifier');
  sessionStorage.removeItem('code_verifier');
  
  const response = await fetch('https://auth.example.com/token', {
    method: 'POST',
    body: new URLSearchParams({
      grant_type: 'authorization_code',
      code,
      redirect_uri: 'https://app.example.com/callback',
      client_id: 'my-spa-client',
      code_verifier: codeVerifier!,  // Sent instead of client_secret
    }),
  });
}

Never use the Implicit Flow (response_type=token). It returns the access token in the URL fragment, which appears in browser history, server access logs, and referrer headers. The Authorization Code flow with PKCE provides equivalent convenience without URL token exposure.

Scope creep: request only what you need:

# Bad: requesting all available permissions
scope=openid profile email phone address admin:read admin:write offline_access

# Good: request minimum required for the current feature
scope=openid profile email

# Request additional scopes incrementally when needed
# User grants 'email' on initial login, only prompt for 'drive:read' when the feature is first used

Validate scopes on the resource server: do not trust the client:

# Resource server: validate the token's scope before serving the request
def require_scope(required_scope: str):
    def decorator(func):
        def wrapper(*args, **kwargs):
            token = get_bearer_token(request)
            payload = verify_jwt(token)
            granted_scopes = payload.get('scope', '').split()
            
            if required_scope not in granted_scopes:
                raise PermissionError(f'Required scope: {required_scope}')
            
            return func(*args, **kwargs)
        return wrapper
    return decorator

@require_scope('profile:write')
def update_profile(request):
    ...

Access token storage: avoid localStorage:

// Bad: localStorage is accessible to any JavaScript on the page (XSS risk)
localStorage.setItem('access_token', token);

// Better: httpOnly cookie (JavaScript cannot read it, prevents XSS token theft)
// Set by the server after token exchange:
// Set-Cookie: access_token=<token>; HttpOnly; Secure; SameSite=Strict; Path=/api

// For SPAs that must store tokens client-side:
// Use sessionStorage (cleared on tab close, not accessible cross-origin)
// Accept that XSS = token theft: mitigate XSS rather than relying on storage security
sessionStorage.setItem('access_token', token);

// Short-lived access tokens (15 minutes) with refresh tokens limit the XSS theft window
// Even if a token is stolen, it expires quickly

Token lifetime guidelines:

• Access tokens: 15 minutes maximum for sensitive scopes, 1 hour for low-sensitivity
• Refresh tokens: Rotate on each use (refresh token rotation), expire after 30 days
• ID tokens: 1 hour (used for identity only, not resource access)