Lion Cipher Lab
Log in a device with the OAuth 2.0 device flow
- Identity & Access Management
- Intermediate
- ~50 min
- Free · no account required
Why it matters
Every time you log a smart TV, a games console, a CLI tool (the GitHub CLI, the AWS CLI, kubectl plugins), or a headless IoT gadget into an account, you are using the OAuth 2.0 Device Authorization Grant — RFC 8628, the 'device flow'. It exists because those devices have no browser, no keyboard, or both: you can't run the normal 'redirect to a login page' dance on a device where typing a password is miserable or impossible. The device flow's trick is to move the login to a device you DO have a good browser on — your phone or laptop — while the constrained device just waits. In this lab you…
What you'll learn
- OAuth 2.0 Device Authorization Grant (RFC 8628)
- the device authorization endpoint (/auth/device)
- device_code, user_code, and verification_uri
- polling the /token endpoint with grant_type=urn:ietf:params:oauth:grant-type:device_code
- handling authorization_pending and slow_down
- device_code expiry and the polling interval
- why input-constrained devices can't use the browser flow
- user_code entropy and verification-flow phishing
- running a real authorization server (Keycloak)
Steps in this lab
- When you'd reach for the device flow — and when you must not
- Start a real authorization server: Keycloak in Docker
- Create a realm, a user, and a public client with Device Grant enabled
- Act as the device: call the device authorization endpoint
- Act as the human: approve at the verification URI on a second screen
- Act as the device again: poll the /token endpoint
- Decode the tokens to prove who logged in
- The sharp edges: user_code entropy, phishing, and why not a browser app