OAuth 2.0 and OpenID Connect
Delegated access without sharing passwords: the authorisation code flow with PKCE step by step, which grant fits which client, and how an ID token differs from an access token.
30 min6 steps
By the end you can
- Put the steps of the authorisation code flow with PKCE in order
- Explain what PKCE prevents and where its strength comes from
- Choose the OAuth grant for a given client type, and recognise deprecated grants
- Distinguish an OpenID Connect ID token from an OAuth access token and use each correctly
Delegation without the password
OAuth 2.0 (RFC 6749) replaces sharing your password with a scoped, revocable token.
The authorisation code flow with PKCE
The browser carries only a short-lived code. Tokens come over a direct back-channel. PKCE (RFC 7636) sends a hash (code_challenge) out and must present the code_verifier back. state ties the response to the request.
Order the steps of the authorisation code flow with PKCE.
- 1The client generates a random code_verifier and computes code_challenge = BASE64URL(SHA-256(code_verifier))
- 2The client calls the resource server with the access token
- 3The user authenticates at the authorisation server and approves the requested scopes
- 4The authorisation server redirects back to the registered redirect_uri with a code and the same state
- 5The authorisation server checks that SHA-256 of the verifier matches the stored challenge, then returns the access token
- 6The client redirects the browser to the authorisation endpoint with response_type=code, client_id, redirect_uri, scope, state and the code_challenge
- 7The client checks state, then sends the code and the code_verifier to the token endpoint
What PKCE protects
On a phone another app can claim the same URL scheme and grab the code. With PKCE the code is useless without the verifier. RFC 9700 recommends PKCE for every client. RFC 7636: 32 random bytes, 43 base64url characters.
Random bytes
32
256 bits
Encoded length
43 chars
base64url
Loading question…
Choose the grant for the client
Browser or native app
- Code + PKCE
- Public client: no secret
Server-side web app
- Code + PKCE
- Plus client secret or key
No user (batch job)
- Client credentials
Deprecated
- Implicit: tokens leak in URL
- Password grant: must not be used
OpenID Connect: who signed in
OAuth says what a client may access. OpenID Connect adds who: scope openid returns a signed ID token (aud = the client). The access token is for the API. Never send an ID token to an API.
ID token
- Audience: the client
- Proves who signed in
- Has sub, nonce
Access token
- Audience: the resource server
- Says what is allowed
- Send this to APIs
Check your mastery
Score 80% or more.
Mastery check
3 questions on fresh variants. One attempt each, no time limit. Score 80% or more to master the lesson.
Answer this step to continue.