IETF · September 2015
RFC 7636
N. Sakimura, J. Bradley, N. Agarwal
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
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.