Protocols and how-tos
The OAuth device authorization flow for TVs, CLIs and IoT
How the device authorization grant lets an input-constrained device or CLI sign a user in via a second screen, and the phishing risk to design around.
The short answer
The device authorization grant (RFC 8628) lets a device with no browser or keyboard — a TV, a CLI on a remote server, an IoT device — sign a user in. The device gets a short user code and a URL, the user enters the code on their phone or laptop and authenticates there, and the device polls the token endpoint until the authorization completes.
Sources last reviewed .
The flow
- The device POSTs its client_id to the device authorization endpoint and receives device_code, user_code, verification_uri, an expiry and a polling interval.
- It shows the user the code and URL (often as a QR code with verification_uri_complete).
- The user opens the URL on another device, signs in, confirms the code and approves.
- Meanwhile the device polls the token endpoint with the device_code, honouring the interval and slow_down responses, until it receives tokens or the code expires.
The risk
RFC 8628 section 5.4 describes remote phishing: an attacker starts a flow and persuades a victim to enter the attacker's code, granting the attacker's device access to the victim's account. Mitigations are on the approval screen — show clearly which application and device is requesting access, and never auto-approve from a link.
In Authreads
How this applies to Authreads
The device authorization grant is not listed on the Authreads roadmap. This guide is general reference.
Authreads is a multi-tenant identity platform in beta. Capability status is maintained on /roadmap as Available, In progress or Planned.
Building on any of this?
Tell us what you're putting together. We'll tell you plainly whether Authreads fits it.