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

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?