What is PKCE and Why Every OAuth 2.0 App Needs It

PKCE — Proof Key for Code Exchange, defined in RFC 7636 — closes the authorization code interception attack in OAuth 2.0. The flow works like this: before redirecting to the authorization endpoint, the client generates a random code_verifier string (43–128 characters), hashes it with SHA-256 to produce a code_challenge, and sends the challenge to the authorization server. When the authorization code arrives at the redirect URI, the token endpoint requires the original code_verifier to issue an access token. An attacker who intercepts the authorization code cannot exchange it without the verifier. PKCE was originally designed for mobile and single-page applications that cannot safely store a client_secret, but RFC 9700 (OAuth 2.1) now requires PKCE for all public clients — including browser-based apps using Auth0, Okta, AWS Cognito, Azure AD, and Keycloak. You can verify that any of these providers declares PKCE support by checking code_challenge_methods_supported in their OpenID Connect discovery document at /.well-known/openid-configuration.

The easiest way to confirm an identity provider's PKCE status, supported grant types, and full discovery configuration is to scan it with the OIDC Inspector. Enter any domain — it checks the primary domain plus 11 common auth subdomains (auth., login., sso., id., accounts., and more) in parallel, parses the discovery document, and surfaces the code_challenge_methods_supported, grant_types_supported, and JWKS URI. If S256 is absent from the challenge methods list, the provider does not support PKCE — a configuration worth flagging in any security review.