OAuth 2.0 Authorization Code + PKCE Lab (Interactive)
Run the flow with and without PKCE while a request interceptor stalks the redirect. Step through authorization code, implicit, and client-credentials grants with an attacker tapping the redirect URI, proving why RFC 7636 verifiers defeat code theft.
OAuth 2.0 Grant & PKCE Interception Lab
Step through delegated authorization as a hijacker app lurks on the device, and compare four grant types.
1. Client generates code_verifier
crypto-random 43-char secret held in memory only: PwrQb-YdvHckp8Ou3Z…
- ▶1. Client generates code_verifier
- ·2. Client derives code_challenge
- ·3. GET /authorize with challenge + state
- ·4. Resource Owner logs in & consents scopes
- ·5. 302 redirect_uri?code=8832&state=xyz
- ·6. POST /oauth/token (code + proof)
- ·7. Call /api/v1/orders with Bearer access_token
OAuth is authorization, not authentication — add OIDC's ID token for identity.
Roles: Resource Owner → user; Client → your app; Authorization Server → Auth0/Okta; Resource Server → your API.
Public clients (SPA, mobile) cannot hold a secret, so PKCE creates a per-login dynamic one instead. Always validate the state parameter against CSRF.
How It Works Under the Hood
OAuth 2.0 delegates access without ever sharing passwords, but public clients such as mobile and SPAs cannot protect a client secret, so the browser history and redirect URI leak the authorization code. An interceptor that captures the code can normally redeem it at the token endpoint. PKCE fixes this: the client generates a high-entropy verifier, sends its SHA-256 challenge up front, and the token endpoint demands the original verifier, which never crosses the intercepted channel. The simulator walks each grant step by step with the attacker toggled on, contrasting implicit's URL-fragment token leakage with the modern code-plus-PKCE recommendation.
Core Architectural Principles
- The one-time code is worthless to the interceptor without the per-flow code_verifier held in the client.
- Implicit grant tokens appear in the URL fragment and history, which is why it is deprecated for new apps.
- Machine-to-machine client credentials need no user browser: secrets or JWT assertions replace the code dance.
Name the roles precisely: resource owner, client, authorization server, and say authorization code with PKCE is the current default for every public client. Explain the verifier-challenge pair defeats interception because only the challenge traverses the redirect, mention state parameters against CSRF, and note refresh token rotation for mobile apps.
PKCE adds one client-side round trip of crypto in exchange for making stolen authorization codes unredeemable.