OAuth 2.0 PKCE transition: Enforcing S256 challenge methods for public clients

Question

Transitioning from static secrets to PKCE
Public clients in OAuth 2.0 are moving away from the use of client_secret due to the inability to securely store credentials in client-side applications. The implementation of Proof Key for Code Exchange (PKCE) as defined in RFC 7636 addresses this by introducing a code_verifier and code_challenge to bind the authorization request to the token exchange.

Challenge Method Constraints
The specification allows for two challenge methods: plain and S256. While S256 is the recommended security baseline, some identity provider implementations maintain backward compatibility by allowing plain or failing to enforce the presence of a challenge entirely for certain client types.

When configuring an authorization server to strictly require PKCE for all public clients, there is uncertainty regarding how to handle clients that cannot support SHA-256 hashing without breaking existing integrations.

Should the server reject all plain requests to maintain a high security posture?
How should the server behave when a public client omits the code_challenge during the initial authorization request?

Tasadduq Burney · Answer

To maintain a high security posture, the authorization server should reject all requests using the plain challenge method and fail any public client requests that omit the code_challenge.
Transitioning public clients from static secrets to Proof Key for Code Exchange (PKCE) is a critical security upgrade. While RFC 7636 defines the plain method for backward compatibility, it provides no protection against code injection attacks because the code_verifier is sent in clear. For modern applications, S256 is the only acceptable baseline.

Implementation Steps for Enforcement
If you are configuring an authorization server to strictly enforce PKCE, follow these steps to ensure a secure transition:

Identify Public Clients: Map all clients that cannot securely store a client_secret (e.g., mobile apps, single-page applications).
Enable Mandatory PKCE Requirement: Update the server configuration to require code_challenge for these specific client IDs.
Restrict Challenge Methods: Set the policy to reject any authorization request containing an invalid_request error if the code_challenge_method is not S256.
Handle Omissions: Ensure the server returns an invalid_request error or a specific pkce_required error when the challenge is missing.

Handling Legacy Integrations
The primary uncertainty lies in clients that may not support SHA-256 hashing. In a modern ecosystem, the lack of SHA-256 support is considered a significant technical debt. If a client truly cannot perform hashing, it should not be considered a public client, or it must be refactored to use a backend proxy (BFF pattern) that can handle the secret securely. The server should not allow plain for public clients, as this violates the security assumptions of the modern OAuth 2.0 specifications.

To verify your enforcement, you can use the following command to attempt an insecure request:
# This should return an error from your server if configured correctly
curl -G "https://auth.example.com/authorize?response_type=code&client_id=public_client_id&redirect_uri=https://app.com/callback&code_challenge=test_challenge&code_challenge_method=plain"

OAuth 2.0 PKCE transition: Enforcing S256 challenge methods for public clients

Transitioning from static secrets to PKCE

Challenge Method Constraints

1 answer

To maintain a high security posture, the authorization server should reject all requests using the `plain` challenge method and fail any public client requests that omit the `code_challenge`.

Implementation Steps for Enforcement

Handling Legacy Integrations

Your perspective belongs here.

0 question comments