OAuth 2.0 and OIDC basics
On this page 8 topics
Overview
Topics
- Roles
- flows
- authorization server
- resource server
- login vs API authorization
Learn first
2.5 h of practice (estimate)
Learning outcomes
- Name the OAuth 2.0 roles (resource owner, client, authorization server, resource server).
- Explain the authorization code flow with PKCE and the client credentials flow, and when each applies.
- Distinguish OAuth 2.0 (delegated API access) from OIDC (login, ID tokens).
- Configure the Shop API as a resource server trusting an external authorization server.
Lessons
Lab and exercises
Lab
JNR-039-LAB1 · External identity
Outcomes: 1–4 · Time: ~2.5 h Run Keycloak locally, obtain tokens with Postman, and switch the Shop API to validate Keycloak-issued tokens, mapping realm roles to authorities. Acceptance: self-issued tokens from JNR-038 are no longer accepted.
Exercises (assessment: flow-selection scenarios)
| ID | Outcome | Task |
|---|---|---|
| JNR-039-EX01 | 1 | Name the four OAuth roles in this setup: a user, the Shop web app, Keycloak, the Shop API. |
| JNR-039-EX02 | 2 | Choose the flow: (a) a single-page app where users log in; (b) a nightly job calling an internal API; (c) a mobile app. |
| JNR-039-EX03 | 2 | Explain in your own words what PKCE protects against. |
| JNR-039-EX04 | 3 | Fill in a table of access token vs ID token: purpose, audience, sent to the API or not. |
| JNR-039-EX05 | 3 | A team sends the ID token to the API as a bearer token. Explain the problem. |
| JNR-039-EX06 | 4 | Write the YAML and converter to map realm_access.roles to ROLE_* authorities. |
| JNR-039-EX07 | 2 | Say why the implicit and password grants should not be used in new systems. |
Show solutions
- EX01 User: resource owner; Shop web app: client; Keycloak: authorization server; Shop API: resource server.
- EX02 (a) authorization code + PKCE; (b) client credentials; (c) authorization code + PKCE.
- EX03 A stolen authorization code cannot be exchanged for tokens without the original
code_verifier. - EX04 Access token: authorizes API calls, audience is the API, sent to the API. ID token: tells the client who logged in, audience is the client, never sent to the API.
- EX05 The ID token is meant for the client; its audience is wrong for the API, and it is not designed to authorize access.
- EX06 Set
issuer-uri; in aJwtAuthenticationConverterread therealm_accessclaim'sroleslist and map each tonew SimpleGrantedAuthority("ROLE_" + role.toUpperCase()). - EX07 Implicit exposes tokens in the browser URL; password grant makes the client handle user passwords. Both are discouraged by current best-practice guidance (verify before recording).
Quiz
Outcomes: O1 roles · O2 flows and PKCE · O3 OAuth vs OIDC · O4 resource server configuration.
A self-check for you: nothing is graded, saved or sent anywhere. Choose an answer, then check it. You can try again as often as you like.
Practical part
Seven exercises JNR-039-EX01 to EX07 plus the lab; the flow-selection scenarios (EX02, EX07) are the assessment. Pass: at least six exercises correct, correct flow chosen in every scenario, and old self-issued tokens rejected.
Common mistakes
The implicit or password grant in new systems; using ID tokens to call APIs.
Assessment
Flow-selection scenarios.
Career relevance
Advanced API security (MID-051) and identity federation (ARC-027).