Cybersecurity glossary
What is Proof Key for Code Exchange (PKCE)?
Learn what PKCE is, how code_verifier and code_challenge stop authorization code interception, why public clients need PKCE, and how to implement it correctly with OAuth.
Definition
Proof Key for Code Exchange (PKCE) is an OAuth 2.0 extension that binds an authorization code to the client that started the flow by requiring a one-time code_verifier at token exchange that matches a previously sent code_challenge, mitigating authorization code interception.
Why authorization codes needed a proof of possession
Mobile apps and single-page apps cannot hide client secrets. If an attacker steals an authorization code from a redirect, they might redeem it first. PKCE makes redemption require a high-entropy verifier that never left the legitimate client.
It is now considered baseline for authorization code flows—not an optional mobile-only trick.
How PKCE works
Create code_verifier
Generate a high-entropy random string and keep it in the client.
Derive code_challenge
Compute S256 hash (recommended) and send it on the authorize request.
User authenticates
Authorization server records the challenge with the issued authorization code.
Exchange code + verifier
Token request includes the original code_verifier.
Server verifies match
Token endpoint accepts only if verifier maps to the stored challenge.
What PKCE stops—and what it does not
| Threat | PKCE helps? | Also need |
|---|---|---|
| Stolen auth code redeemed by attacker | Yes | Exact redirect URIs, short TTL |
| Redirect CSRF / login CSRF | No | OAuth state |
| ID token injection | No | OIDC nonce + validation |
| XSS stealing tokens after issue | No | Secure storage, short tokens, DPoP/mTLS |
Implementation essentials
High-entropy verifiers
Follow RFC length/entropy guidance; never use predictable values.
Prefer S256
Use code_challenge_method=S256; disable plain in modern deployments.
One verifier per attempt
Generate fresh PKCE material for every authorize request.
Server-side enforcement
Authorization servers must reject exchanges without a matching verifier.
All client types
Apply PKCE to public and confidential authorization-code clients.
Library support
Use maintained OAuth/OIDC SDKs rather than hand-rolled PKCE.
Checklist
- Require PKCE for authorization code grants in your authorization server policy.
- Generate a new code_verifier for each login attempt.
- Send S256 code_challenge on authorize; verify at token endpoint.
- Combine PKCE with exact redirect URI allowlists and short-lived codes.
- Still validate state (and OIDC nonce) on the client.
- Avoid embedding client secrets in mobile or SPA binaries as a PKCE substitute.
- Monitor token endpoint failures that indicate challenge mismatches.
- Retire implicit grant in favor of authorization code + PKCE.
The practical takeaway
PKCE proves that the client redeeming an authorization code is the same one that started the login. It is essential for public clients and recommended for everyone using the authorization code grant.
Pair it with state, nonce, strict redirects, and short-lived tokens—PKCE is powerful, not a complete OAuth security program by itself.
Related security terms
Authorization Code
Short-lived code that PKCE protects during redemption.
OAuth 2.0
Framework extended by PKCE for safer public-client flows.
OAuth Client
Public and confidential clients should use PKCE for auth code grants.
OAuth `state`
CSRF control used alongside PKCE—not a substitute.
OAuth Misconfiguration
Often includes missing PKCE on mobile and SPA apps.
Frequently asked questions
What is PKCE in simple terms?
When an app starts OAuth login, it creates a secret (code_verifier) and sends only a hash of it. Later, when exchanging the authorization code for tokens, it must prove it still knows the original secret—so a stolen code alone is not enough.
Which RFC defines PKCE?
RFC 7636 defines Proof Key for Code Exchange by OAuth Public Clients.
Do confidential clients need PKCE?
Yes, modern guidance recommends PKCE for all authorization code clients, including confidential ones, as defense in depth.
What is S256?
The recommended challenge method: code_challenge = BASE64URL(SHA256(code_verifier)). Avoid plain when S256 is available.
Does PKCE replace client secrets?
No. Public clients cannot hold secrets; PKCE protects them. Confidential clients should still authenticate and also use PKCE.
Does PKCE replace state or nonce?
No. PKCE stops code interception/redemption by others. State stops redirect CSRF. Nonce binds OIDC ID tokens.
What breaks if PKCE is misimplemented?
Reusable verifiers, predictable verifiers, accepting plain when S256 was advertised, or skipping verifier checks at the token endpoint.
References
Explore authoritative guidance and frameworks related to proof key for code exchange (pkce).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.