Replay Attacks Mitigation

Mitigating Replay Attacks with PKCE

In the OAuth 2.0 authorization code flow, public clients (e.g., single-page applications, mobile apps) cannot securely store client secrets. This exposes them to replay attacks, where an attacker intercepts an authorization code and reuses it to exchange for tokens without the client's knowledge. The Proof Key for Code Exchange (PKCE) mechanism addresses this by binding the authorization code to a session-specific, one-time-use verifier, ensuring the code cannot be reused across sessions.

---

How PKCE Prevents Replay Attacks

PKCE introduces two critical components to secure the authorization code flow: 1. Code Verifier: A random, session-specific string generated by the client. 2. Code Challenge: A cryptographic hash of the code verifier, sent to the authorization server during the authorization request.

Key Mechanism

• The client generates a code verifier (e.g., random_string) and computes its hash using a cryptographic algorithm (e.g., SHA-256). The code challenge is the base64-encoded hash of this verifier.
• The client sends the code challenge to the authorization server during the authorization_code flow. The server stores this challenge and issues an authorization code.
• During token exchange, the client includes the original code verifier in the request. The server verifies that the hash of the verifier matches the stored code challenge. If they match, the code is valid; otherwise, it is rejected.

This binding ensures that even if an attacker intercepts the authorization code, they cannot reuse it without the corresponding code verifier, which is tied to the client's session.

---

Step-by-Step Flow

1. Client generates code verifier and challenge
   

   import hashlib
   import base64
   import os
   
   verifier = base64.urlsafe_b64encode(os.urandom(32)).decode('utf-8')
   challenge = base64.urlsafe_b63encode(hashlib.sha256(verifier.encode()).digest()).decode('utf-8')
   

2. Authorization request with code challenge
   

   GET /authorize?client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&response_type=code&scope=openid&code_challenge={challenge}&code_challenge_method=SHA256
   

3. Authorization server issues authorization code
   The server stores the challenge and issues a code to the client.

4. Token exchange with code verifier
   

   POST /token
   client_id=CLIENT_ID&code=AUTHORIZATION_CODE&grant_type=authorization_code&code_verifier={verifier}
   

5. Server validates code challenge
   The server hashes the verifier and compares it to the stored challenge. If valid, tokens are issued.

---

Diagram: PKCE Flow and Replay Attack Mitigation

Client → [Authorization Server]  
│                            ↓  
│  Generate Verifier → Compute Challenge → Send Code Challenge  
│                            ↓  
│  Authorization Code Issued → Client Redirects to Redirect URI  
│                            ↓  
│  Client Exchanges Code → Include Verifier → Server Validates Challenge  
└──────────────────────────────────────────────────────────────┘

---

Critical Security Properties

• Session Binding: The code challenge is tied to a specific client session, making replaying the code ineffective.
• One-Time Use: The code verifier is ephemeral and cannot be reused across sessions.
• Cryptographic Binding: The hash ensures the code challenge is tamper-resistant.

---

Example: Replay Attack Without PKCE

• An attacker intercepts the authorization code and reuses it in a token exchange request.
• Since the client lacks a secret, the server cannot validate the request, and the code is rejected.

---

Key takeaways

• PKCE prevents replay attacks by binding the authorization code to a session-specific code verifier.
• The code challenge ensures the code is tied to the client's session, making interception ineffective.
• The use of a one-time code verifier and cryptographic hashing guarantees the code cannot be reused without the corresponding verifier.