Lion Cipher Lab
Require stronger auth for sensitive actions: step-up authentication with Keycloak
- Identity & Access Management
- Intermediate
- ~75 min
- Free · no account required
Why it matters
Not every action deserves the same level of trust. Reading your balance is low-stakes; wiring the balance to a stranger is not. Yet most apps authenticate you once at the door and treat that single login as a blanket permission for everything you do all session — so a stolen session cookie or an unlocked laptop becomes a transfer, a deletion, or an admin change. Step-up authentication fixes this: it demands stronger or fresher proof at the moment of a high-value action, not just at login. This is how banks re-prompt before a transfer and how cloud consoles re-ask before you delete production.…
What you'll learn
- step-up authentication
- Keycloak Level of Authentication (LoA)
- conditional authentication flows
- the acr and amr claims
- mapping acr values to authentication levels
- forcing a higher LoA with the claims / acr_values request parameters
- max_age for re-authentication freshness
- verifying acr in the client (RFC 9470)
Steps in this lab
- What step-up authentication is — and the problem it solves
- acr and amr: the claims that carry 'how strongly did they log in'
- Start a real authorization server: Keycloak in Docker
- Create a realm, a user, and a public client
- Map acr values to Levels of Authentication (LoA)
- Build the step-up flow: a conditional OTP subflow at LoA 2
- Log in normally and confirm acr = 1
- Demand a higher level and watch Keycloak step up
- Freshness, not just strength: what max_age forces
- The half everyone forgets: the CLIENT must verify acr (RFC 9470)
- When, why, and the better factor — using step-up well