PKCE for the authorization code flow

Clients must prevent authorization code injection and misuse of authorization codes. Public clients MUST use PKCE (RFC 7636); for confidential clients PKCE is RECOMMENDED, because it strongly protects against misuse and injection of authorization codes and, as a side effect, prevents CSRF even in the presence of strong attackers. Confidential OpenID Connect clients MAY instead use the nonce parameter, with additional precautions. The PKCE challenge or nonce MUST be transaction-specific and securely bound to the client and the user agent in which the transaction was started. Although PKCE was designed to protect native apps, this advice applies to all OAuth clients, including web applications. Clients SHOULD use a code challenge method that does not expose the verifier in the authorization request; S256 is currently the only such method. Authorization servers MUST support PKCE, MUST enforce correct use of code_verifier at the token endpoint when a valid code_challenge was sent, and MUST mitigate PKCE downgrade attacks by accepting a token request containing code_verifier only if a code_challenge was present in the authorization request. Publishing code_challenge_methods_supported in RFC 8414 authorization server metadata is RECOMMENDED. Scope: OAuth 2.0 security. Reviewed October 4, 2026.