Reading PKCE and Security Requirements in the OAuth 2.1 Draft
OAuth 2.1 is still an IETF draft. This guide separates the published baseline in RFC 9700 from draft language on PKCE, redirect URIs, and refresh tokens, then turns the distinctions into deployment checks.
Publication & corrections: infostoa · Editorial standards
Individual author and specialist reviewer information is not provided for this article.
Start by checking the document status
On 2026-10-12, the IETF Datatracker listed draft-ietf-oauth-v2-1-16 as an Active Internet-Draft. It had no assigned RFC status. An Internet-Draft is work in progress, so do not cite OAuth 2.1 as a finalized specification. For requirements already in force as published guidance, consult OAuth Security Best Current Practice, RFC 9700; read OAuth 2.1 as a draft that consolidates and may still change that guidance.
What PKCE binds—and what it does not
PKCE binds an authorization request to its later token exchange using a one-time code_verifier. For each request, the client creates an unpredictable verifier and sends a derived code_challenge to the authorization endpoint. The client must present the verifier at the token endpoint to redeem the code. This reduces the risk that someone who intercepted only the authorization code can redeem it with their own verifier. PKCE does not protect an access token after issuance or prevent browser XSS.
RFC 9700 currently says public clients MUST use PKCE and RECOMMENDS it for confidential clients. The OAuth 2.1 draft’s default authorization-code flow also includes PKCE parameters, with a code_challenge exception only when the specific conditions in §7.5.1 are met. The draft requires a challenge method that does not expose the verifier and currently identifies S256 as the only such method. This does not make PKCE a requirement for every OAuth grant, nor does it replace client authentication secrets. PKCE and client authentication serve different purposes.
Four deployment checks, with status kept visible
| Topic | Published baseline | OAuth 2.1 draft direction | What to inspect in a deployment |
|---|---|---|---|
| PKCE | RFC 9700: MUST for public clients, RECOMMENDED for confidential clients | Included by default in the authorization-code flow; check the §7.5.1 exception and S256 wording | Does each SPA/native request create a fresh verifier and use S256? Does a server app retain its separate client authentication? |
| Redirect URIs | RFC 9700 §2.1: exact string matching against registered URIs is MUST; native-app localhost ports are excepted | Refers to the RFC 9700 rule | Check provider comparison behavior and the limited native loopback exception |
| Public-client refresh tokens | RFC 9700 §2.2.2: MUST be sender-constrained or use rotation | Draft summarizes public-client tokens as sender-constrained or one-time use | Check how the provider detects reuse, invalidates tokens, and supports recovery |
| Legacy grants | RFC 9700 says clients SHOULD NOT use the implicit grant, subject to its stated mitigations, and says the password credentials grant MUST NOT be used | Both are omitted from the draft | Check app configuration and logs for these grants and plan an authorization-code replacement |
The localhost exception is not permission for arbitrary wildcard matching. RFC 9700 allows the port-number exception for native-app localhost redirects. For other redirect registrations and comparisons, verify the exact scope in the provider configuration and RFC text.
A hypothetical deployment review
Suppose a team operates both a SPA and a server-rendered app. First record each app’s grant and client type from the identity-provider configuration. For the SPA, check that the authorization request sends only the S256-derived code_challenge and code_challenge_method=S256, not the original code_verifier. Keep the verifier in the client and send it only to the token endpoint when redeeming the authorization code. For the server app, confirm client authentication remains separate from PKCE. Compare requested redirect URIs with registrations without extending the native loopback port exception to ordinary web URIs. Finally, use provider documentation and logs to see whether refresh-token reuse for public clients triggers revocation or sender-proof checks. This is a hypothetical review sequence, not a test performed against a product.
Deciding what to adopt
Do not treat “OAuth 2.1” as a single product checkbox. Use the published RFC 9700 guidance to review current settings by client type, and track draft clauses with their version and exceptions. PKCE mitigates authorization-code theft; it does not replace token-storage design or XSS defenses. Decide browser token handling under a separate threat model.
Sources: OAuth 2.1 Internet-Draft, RFC 9700, RFC 7636.