Skip to content

Security Considerations for Authorization Code Flow

The Authorization Code Grant Flow is a foundational OAuth 2.0 flow designed for confidential clients (those capable of securely storing client secrets). While it provides robust security by default, several vulnerabilities and mitigation strategies must be addressed to ensure its safety in real-world deployments.

Cross-Site Request Forgery (CSRF) Protection

Problem

CSRF attacks exploit the trust a user's browser has in a legitimate site. An attacker could trick a user into authorizing a malicious application by forging a request to the authorization endpoint, bypassing the client's security checks.

Mitigation: State Parameter and PKCE

  1. State Parameter: The client generates a random state value and sends it with the authorization request. The server validates this value upon redirect to ensure the request is legitimate.
  2. Proof Key for Code Exchange (PKCE): For public clients (e.g., single-page apps), PKCE adds an extra layer of protection by requiring a code_verifier and code_challenge during the authorization code exchange. This prevents interception of the authorization code.

Example: PKCE Flow 

GET /authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&state=STATE&code_challenge=CODE_CHALLENGE HTTP/1.1
Host: authorization-server.com


POST /token HTTP/1.1
Host: authorization-server.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=REDIRECT_URI&code_verifier=CODE_VERIFIER

Authorization Code Interception

Problem

If an attacker intercepts the authorization code (e.g., via a man-in-the-middle attack), they can exchange it for an access token without user interaction.

Mitigation: PKCE and Secure Channels

  • PKCE: Ensures the authorization code is only valid for the specific client and code verifier, making interception useless.
  • HTTPS: Always use HTTPS to encrypt communication between the client, authorization server, and resource server.

Token Leakage and Secure Storage

Problem

Access tokens (and refresh tokens) can be leaked through insecure storage, logging, or misconfigured APIs. Once exposed, attackers can impersonate the user or access protected resources.

Mitigation

  1. Secure Token Storage: Use encrypted storage for tokens on the client side (e.g., secure HTTP-only cookies or local storage with encryption).
  2. Token Rotation: Implement refresh token rotation to invalidate old tokens after a new one is issued.
  3. Short-Lived Access Tokens: Limit token lifetimes to reduce exposure if leaked.

Example: Token Rotation 

POST /token HTTP/1.1
Host: authorization-server.com
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=OLD_REFRESH_TOKEN

Client Secret Protection

Problem

Confidential clients must securely store their client secrets. If compromised, an attacker can impersonate the client and request tokens without user interaction.

Mitigation

  • Secure Storage: Use environment variables, secret managers (e.g., HashiCorp Vault), or encrypted configuration files.
  • PKCE for Public Clients: Public clients (without secrets) must use PKCE to prevent code interception.

Redirect URI Validation

Problem

Open redirect vulnerabilities allow attackers to redirect users to malicious domains after authorization, stealing credentials or phishing users.

Mitigation

  • Pre-registered Redirect URIs: Clients must register valid redirect URIs with the authorization server. The server validates that the redirect URI matches the registered ones.
  • Strict Validation: Reject any authorization response with an unregistered redirect URI.

Example: Redirect URI Validation 

GET /authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=https://myapp.com/callback HTTP/1.1
Host: authorization-server.com

Diagram: Authorization Code Flow with PKCE

User → [Redirect to Authorization Server] → 
        ↓
[Authorization Server] → User grants consent → 
        ↓
[Authorization Server] → Redirects to Client with code → 
        ↓
Client → [Exchange code for token] → 
        ↓
[Resource Server] → Returns protected resource

Key takeaways

  • Use PKCE for public clients to prevent CSRF and code interception.
  • Validate redirect URIs strictly to avoid open redirect attacks.
  • Protect client secrets with secure storage and encryption.
  • Secure token storage and rotation to mitigate leakage risks.
  • Always use HTTPS to encrypt all communication in the flow.