Lion Cipher Lab
Authenticate a user out-of-band with OIDC CIBA
- Identity & Access Management
- Advanced
- ~60 min
- Free · no account required
Why it matters
Imagine phoning your bank. The agent needs to prove it's really you before discussing your account — but you must NEVER read your password or a one-time code to a stranger on a phone line, and the agent's screen must never touch your credentials. CIBA — Client-Initiated Backchannel Authentication, an OpenID Connect extension — is how that's done properly: the agent's app (the Relying Party) starts an authentication in the background, and a push notification lands on YOUR phone asking 'Approve login for your account?'. You approve on your own trusted device, and the agent's screen simply…
What you'll learn
- OpenID Connect Client-Initiated Backchannel Authentication (CIBA)
- the backchannel_authentication_endpoint and how to discover it
- starting a login with login_hint + scope + binding_message to get an auth_req_id
- polling the token endpoint with grant_type=urn:openid:params:grant-type:ciba
- handling authorization_pending and slow_down while the user approves out-of-band
- poll vs ping vs push delivery modes and why the client must be confidential
- the binding_message as a defence against blind-approval attacks
- choosing CIBA vs the device flow vs Authorization Code + PKCE
Steps in this lab
- When you'd reach for CIBA — and when you must not
- Start a real authorization server: Keycloak in Docker
- Create a realm and a user who will approve on a second device
- Register a CONFIDENTIAL CIBA client in poll mode
- Discover the backchannel_authentication_endpoint
- Act as the RP: start the backchannel authentication request
- Act as the user: approve out-of-band on the second device
- Act as the RP again: poll the token endpoint for the result
- Decode the id_token to prove who was authenticated
- The sharp edges: binding_message, delivery modes, and CIBA vs the rest