IDSync — identity software buyer platform
Run Stack Finder

Standards

Proof Key for Code Exchange (PKCE)

Proof Key for Code Exchange (PKCE, pronounced 'pixie') is an OAuth 2.0 extension (RFC 7636) that protects the authorization code flow from interception attacks by requiring the client to prove it initiated the original authorization request.

Last reviewed 5/30/2026

Key points

  • PKCE replaces the OAuth implicit flow for SPAs and mobile apps — the implicit flow is officially deprecated.
  • Flow: client generates a random code_verifier, sends SHA-256(code_verifier) as code_challenge with the auth request, then proves possession by sending the raw code_verifier when exchanging the code for tokens.
  • Required for public clients (mobile, SPA, CLI). Recommended for all OAuth clients in OAuth 2.1.
  • Defends against authorization-code interception (malicious app on the same device, browser history leaks, log files).
  • Modern IdPs (Okta, Auth0, Entra ID, Google, Cognito, Keycloak) all support PKCE.

What is PKCE?

Proof Key for Code Exchange (PKCE, RFC 7636, pronounced "pixie") is the OAuth 2.0 extension that makes the authorization code flow safe to use without a client secret — which is exactly the situation every mobile app, single-page app, CLI, and desktop app is in.

Before PKCE, public clients had two bad options: use the implicit flow (which returned tokens directly in URL fragments — leaky and unrevokable) or hardcode a "client secret" that wasn't actually secret. PKCE solves both.

How it works

  1. Client generates a random code_verifier — 43–128 chars of high-entropy randomness.
  2. Client computes code_challenge = BASE64URL(SHA-256(code_verifier)) and sends it with the authorization request, along with code_challenge_method=S256.
  3. The authorization server stores the challenge against the issued authorization code.
  4. When the client exchanges the code for tokens, it sends the original code_verifier.
  5. The server hashes it, compares to the stored challenge, and only issues tokens if they match.

Result: even if an attacker intercepts the authorization code (via a malicious app handling the redirect URI, browser history, or a leaked log line), they can't redeem it because they don't have the verifier.

When to use it

Always, in OAuth 2.1. Specifically:

  • Mobile and native apps — mandatory.
  • Single-page apps (SPAs) — mandatory. PKCE replaced the implicit flow here.
  • Confidential clients (backend web apps with a client secret) — recommended. Defense in depth: a stolen client secret alone isn't enough to redeem stolen codes.

Common misconceptions

  • "PKCE replaces a client secret." Partially — for public clients, yes. For confidential clients, you use both.
  • "PKCE prevents phishing." No. It prevents authorization-code interception. Phishing-resistant MFA (FIDO2) prevents phishing.
  • "plain method is fine." Don't. Always use S256. Some IdPs reject plain outright.

Editorial note

If you're evaluating an IdP and it doesn't support PKCE, walk away. Every credible OAuth provider has supported it for years. If you're building an OAuth client, use a vetted library (AppAuth, MSAL, oauth4webapi) rather than rolling your own — getting PKCE right is easy, getting all of OAuth right is not.

Standards & references