5 exercises on OAuth2 advanced concepts — PKCE, authorization code flow, token introspection, and refresh rotation.
0 / 5 completed
1 / 5
What problem does PKCE (Proof Key for Code Exchange) solve?
PKCE (RFC 7636): a malicious app on the device could intercept the authorization code from the redirect URI. PKCE adds a code_verifier/code_challenge pair: the challenge is sent upfront and the verifier is sent at token exchange — only the original app can complete the flow.
2 / 5
In the PKCE flow, what is the relationship between code_verifier and code_challenge?
code_verifier / code_challenge: the client generates a random 43–128 character verifier, hashes it (S256), and sends the hash as code_challenge with the auth request. At token exchange it sends the plain verifier. The server hashes it and compares — verifying the same client started the flow.
3 / 5
What is token introspection in OAuth2?
Token introspection (RFC 7662): unlike JWTs (self-contained and verifiable locally), opaque tokens are meaningless strings. Resource servers POST the token to the /introspect endpoint; the AS responds with active status, subject, scope, and expiry.
4 / 5
What is refresh token rotation?
Refresh token rotation: if a refresh token is used more than once (e.g. by an attacker), the authorization server detects the reuse and revokes the entire token family, forcing re-authentication. This is a key security feature in OAuth2 for mobile and SPAs.
5 / 5
What is the authorization code flow and why is it more secure than implicit flow?
Authorization code flow: the access token is never in the URL — the browser only sees a short-lived code that is exchanged server-side (or with PKCE for public clients). The implicit flow (now deprecated) put tokens in URL fragments, risking exposure via referrer headers, browser history, and browser extensions.