Lesson 1.48: OAuth 2.0 done safely: redirect URIs and PKCE
OAuth 2.0 lets an application get a token for a user without ever seeing the user's password: the user logs in at the identity provider, which sends a one-time code back to a registered redirect URI. Most real attacks steal that code or token: through a sloppy redirect URI, an intercepted code on a phone, or a deprecated flow. Today's best practice (RFC 9700) is short: authorization code with PKCE for every client, exact redirect URIs, and no implicit or password grants. In the lab you review the identity provider's client registrations, compute a PKCE challenge yourself, and prepare the fixes.
17 min
You will learn to
- Explain the authorization code flow
- Explain why redirect URIs must match exactly
- Explain PKCE and compute an S256 challenge
- Identify deprecated grants (implicit, password)
- Review client registrations with jq
Key terms
- OAuth 2.0 / OpenID Connect
- A framework to obtain access tokens for APIs / a layer on top that also says who the user is (ID token).
- Authorization code
- A one-time code sent to the redirect URI and exchanged for tokens.
- Redirect URI
- Where the identity provider sends the code; must be registered and matched exactly.
- PKCE
- Proof Key for Code Exchange (RFC 7636): a per-login secret proving the redeemer started the login.
- Public / confidential client
- Can't keep a secret (mobile, browser apps) / runs on a server and can.
- state
- A random value tying the response to the request, against login CSRF.
← Requests, parameters, cookies and sessions · All lessons · Kerberos, NTLM and what they log →