Authorization code flow faces PKCE enforcement decision in OAuth 2.1 draft

Question

The goal is to determine whether an authorization server should treat the Proof Key for Code Exchange (PKCE) extension as a mandatory requirement for the authorization code flow when aligning with the OAuth 2.1 draft, which proposes to make PKCE compulsory for both public and confidential clients, while many existing OAuth 2.0 implementations still accept requests lacking a code_verifier.

Because the OAuth 2.1 specification remains a draft, the final decision on mandatory PKCE is unresolved, creating a compatibility boundary: enabling PKCE by default could break legacy clients that do not send a code_verifier, whereas leaving it optional may delay adoption of the proposed security improvement. Implementers must weigh the risk of draft‑only changes against the need to support current clients.

Should authorization servers enable PKCE enforcement by default when targeting OAuth 2.1 compatibility? What version‑specific flags or configuration options can allow both PKCE‑enforced and non‑PKCE clients to coexist? How can compatibility be validated without locking into a draft‑only behavior that might change before standardization?

Siddharth · Answer

Answer to the Core Question
When an authorization server explicitly targets OAuth 2.1 compatibility, it should treat PKCE as mandatory for the authorization code flow by default. The draft states that all clients—public and confidential—must use PKCE. Enabling PKCE by default aligns with the draft’s security intent and protects against code‑interception attacks.
Confirmed Facts

OAuth 2.1 draft declares PKCE compulsory for every client type.
Many existing OAuth 2.0 deployments still accept authorization requests that omit code_verifier.
Turning on PKCE enforcement without a fallback will break legacy clients that cannot be updated.

Practical Recommendations

Enable PKCE enforcement by default. This ensures compliance with the draft and provides the strongest security posture.
Provide a toggle for legacy clients. Implement a global or per‑client flag, e.g. enforce_pkce: true/false, in the server configuration. Clients that are known to lack PKCE support can be whitelisted.
Document the flag. Clearly communicate the purpose of the toggle so administrators understand the security trade‑off.
Plan a migration window. Inform clients of the upcoming enforcement and give them a timeline to add code_challenge and code_verifier support.

Validation Steps

Deploy a test client that requests an authorization code without code_verifier and verify that the server rejects the request when enforcement is enabled.
Deploy a test client that includes a valid code_challenge and code_verifier pair and confirm successful token exchange.
Toggle the enforcement flag and rerun both tests to ensure the behavior changes accordingly.
If available, run the OAuth 2.1 draft conformance test suite to confirm compliance with PKCE requirements.
Review server logs for explicit PKCE enforcement messages during the test runs.

Missing Diagnostic Detail
Do you have any existing public or confidential clients that cannot be updated to send code_verifier at this time? This information will determine whether a temporary non‑enforced path is necessary.

Authorization code flow faces PKCE enforcement decision in OAuth 2.1 draft

1 answer

Answer to the Core Question

Confirmed Facts

Practical Recommendations

Validation Steps

Missing Diagnostic Detail

Your perspective belongs here.

0 question comments