RFC 7636 / START HERE
PKCE, before the details
PKCE: Proof Key for Code Exchange
PKCE binds an OAuth authorization-code exchange to the application instance that started it. The app keeps a secret verifier and sends a derived challenge first.
The idea in one picture
An app sends a challenge
Authorization returns a code
The verifier proves the same request
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
An intercepted authorization code should not be enough for another party to obtain tokens.
A familiar example
A mobile app starts sign-in with a challenge, then proves it knows the verifier when redeeming the returned code.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- Create a transaction secretThe client creates a fresh, high-entropy verifier for each authorization request.→
- Derive the S256 challengeThe challenge commits the request to the verifier without sending that verifier to the authorization endpoint.→
- The code remembers its challengeThe authorization server associates the challenge and method with the code it issues.→
- A stolen code fails the proofThe token endpoint recomputes the challenge and compares it with the one bound to the code.→
- Do not downgrade the methodAn S256 error is not permission to retry with plain or omit PKCE.→
This introduction explains RFC 7636 (2015). Read the original RFC ↗