IETF · September 2015
RFC 7636
N. Sakimura, J. Bradley, N. Agarwal
Proof Key for Code Exchange by OAuth Public Clients (RFC 7636) is RFC, September 2015. An agent that opens a browser (or a loopback redirect) to get user consent is a public or at-best confidential client in a hostile environment. PKCE is the difference between 'the code in the redirect is enough' and 'only the process that started the flow can finish it'.
At a glance
Actors
Animated sequence · PKCE
Only the process that started the flow can finish it
The client keeps a high-entropy code_verifier. The authorization server only sees a hash (code_challenge, S256). An interceptor who steals the code from the redirect cannot redeem it. OAuth 2.1 keeps only S256; plain is gone. Authentication and consent stay separate hops.
Now · 1/9· Prove· RFC 7636You are here
Client (agent)→Client (agent)·Creates a code_verifier and keeps it
The client generates a fresh code_verifier and holds it in the process that will later call the token endpoint.
Why The secret must never appear on the front channel. A static challenge is not PKCE. Generate a new verifier per authorization request.
Write a secret in the desk drawer.
Solid = from the spec
RFC 7636. OAuth 2.1 keeps only S256; the plain method is gone. Generate a new verifier per authorization request.
Sequence above; this list is the same hops for reading and search. Each row is one message.
Client (agent)→Client (agent)RFC 7636Creates a code_verifier and keeps it
Client (agent)→Client (agent)RFC 7636Derives code_challenge = S256(code_verifier)
Client (agent)→Authorization serverRFC 7636Authorization request carries code_challenge, not the verifier
RO (user)→Authorization serverOAuth 2.1Authenticates at the authorization server
RO (user)→Authorization serverOAuth 2.1Consents to this client
Authorization server→Client (agent)OAuth 2.1Authorization code in the redirect (an interceptor might see this)
Client (agent)→Authorization serverRFC 7636Token request: code + the original code_verifier
Authorization server→Authorization serverRFC 7636Hashes the verifier with S256 and matches the stored challenge
Authorization server→Client (agent)RFC 6750Match — access token. Stolen code without the verifier fails
01
Public clients cannot keep a client secret. An attacker who intercepts the authorization code — custom URI schemes, referrer leakage, a malicious app on the device, a compromised agent helper — can redeem it. PKCE binds redemption to the process that started the request.
Agents that open a browser, a loopback redirect, or a device-code-adjacent window are in this threat model even if someone labelled them 'confidential' in a portal. OAuth 2.1 and RFC 9700 require PKCE for authorization-code clients including confidential ones, because authorization-code injection is not only a native-app problem.
02
The authorization code travels through the user-agent. The code_verifier never does: it stays in the client and appears only on the token-endpoint back channel. The AS is trusted to store the challenge and compare. The RS never sees PKCE parameters.
03
Client creates a high-entropy code_verifier. code_challenge = BASE64URL(SHA256(verifier)) with code_challenge_method=S256. Authorization request carries the challenge; token request carries the verifier. AS accepts the code only if SHA256(verifier) matches. RFC 7636 also defined plain; OAuth 2.1 prohibits it.
Generate a new verifier per authorization request. Do not log verifiers. Pair with exact redirect matching and, for mix-up, RFC 9207 iss.
04
Flow 1
Client generates code_verifier, derives S256 code_challenge.
Authorization request includes code_challenge and code_challenge_method=S256.
After redirect, token request includes code and code_verifier (plus client auth if any).
AS recomputes S256 and compares. Mismatch → invalid_grant.
05
Protects the authorization-code redemption step — client-to-AS authentication of the token request, not user identity. Authorization of the API remains the access token.
06
Folded into the core grant.
RFC 8252 required PKCE for native apps; 2.1 generalized it.
MCP clients doing authorization code MUST use PKCE as OAuth 2.1 clients.
PKCE protects the code; DPoP protects later resource requests. Both are needed if the agent is public and the token is valuable.
07
A static challenge is not PKCE. One verifier per request.
If the AS still allows plain, an interceptor who sees the challenge sees the verifier. Refuse to use plain.
After redemption, a stolen Bearer access token still works. Add DPoP/mTLS/signatures.
08
RFC 7636, September 2015, N. Sakimura, J. Bradley, N. Agarwal. Stable. Required by RFC 9700 and OAuth 2.1. https://www.rfc-editor.org/rfc/rfc7636.html
OAuth 2.1 and RFC 9700 require PKCE for authorization-code clients, including confidential ones. Generate a new verifier per authorization request.