Authorize an application with a code and Proof Key for Code Exchange (PKCE).
The user signs in at the authorization server. The application receives a code, then proves it is the same client that started the flow by using Proof Key for Code Exchange (PKCE).
Why this lesson?
A browser app needs permission to read a customer’s orders. The customer should enter their password only at the sign-in provider.
Learning goal and prerequisites
Request user-approved access
The client creates a high-entropy random code verifier and saves it for this transaction. It sends a code challenge derived from that verifier. The S256 method means the challenge is created with the Secure Hash Algorithm 256-bit (SHA-256) hash function. The user then signs in at the authorization server and approves the requested access.
Inspect request, response, and claims
Try a failure scenario
↳ Change a condition
Read the detailed explanation
Why it exists, how it works, and where it fits
Browser and installed applications often use the OAuth authorization code flow, but these clients cannot safely keep a permanent shared secret. They also receive the authorization result through the browser, where an authorization code could be intercepted or delivered to the wrong application. Proof Key for Code Exchange (PKCE) was designed to protect that code.
Before starting authorization, the client creates a fresh random code verifier and derives a code challenge from it. The client sends the challenge with the authorization request but keeps the verifier private. After the user approves access, the authorization server returns an authorization code through the browser.
When the client exchanges the code for tokens, it sends the original verifier. The authorization server checks that the verifier matches the challenge attached to that authorization request. A party that steals only the authorization code cannot redeem it without the verifier.
PKCE is useful because it binds the code redemption to the client instance that started the flow without depending on a client secret. It does not replace redirect-address validation, the state value, user authentication, or token validation. Each control protects a different part of the authorization flow.
Investigation
Inspect the traffic, select a diagnosis in the checkpoint, then reveal the repair.
Check your understanding
Pass the lesson quiz
Answer every question correctly to unlock the next lesson. Retry as often as you need.