OAuth 2.0 Device Authorization Flow
The Device Authorization Flow is the way a device with no browser and no keyboard gets permission to use an API. Think of a smart TV, a speaker, a gaming console, or a kiosk. It can show things on a screen, but it has no easy way for you to type a password into it.
It is one of the grant types in OAuth 2.0 — a special way of "asking for a token" suited to boxes without a proper login screen.
The real-world example you already know
If you have ever set up a streaming box (Roku, Apple TV, Chromecast, a smart TV), you have done this without knowing it:
- The TV shows a short code on screen — like
K4-7X2— and a website address. - You open that website on your phone or laptop, type the code, log in, and click Allow.
- Back on the TV, it suddenly loads your account.
The code is the bridge between the device (which has no keyboard) and you (who are sitting there with a phone). That is the device flow working in real life.
The big idea: a code bridges the screen and the phone
The whole trick is that the device never asks the human to type a password into it. Instead:
- The device asks the identity server for two things: a device code (a secret the device keeps privately) and a user code (the short code shown on screen, like
K4-7X2). - The human takes the user code somewhere with a real browser, approves it there, far away from the device.
- When the human approves, the server hands the device its tokens — and the device never knew the password.
This is different from the normal flow where an app has a login page. The device flow says: "I can't type, so I'll show you a code and you go approve it on your own device."
How it works, step by step
| Step | What happens | Who does it |
|---|---|---|
| 1 | Device asks the server for a device code and a short user code | Device → server |
| 2 | Device shows the user code and a URL on its screen | Device |
| 3 | Human opens the URL, types the code, logs in, approves | Human (phone/laptop) |
| 4 | Device polls — keeps asking "am I approved yet?" every few seconds | Device → server |
| 5 | As soon as the human approves, the server replies with tokens | Server → device |
| 6 | Device uses the access token, then refreshes it later with the refresh token | Device |
Steps 3 and 4 happen at the same time: the human is approving the request while the device quietly keeps checking for an answer.
The whole conversation, drawn
The repeated "Are we approved yet?" is the polling — the device has no open door for the server to knock on, so instead it knocks on the server itself until it gets an answer.
Why polling instead of a phone call back
In normal computer conversations, when a site is ready it can "call back" to the app. The device flow cannot do that, because the device has no web address of its own and no public port to receive a message on — it sits behind your home router, unseen. So the roles flip: the device calls the server, not the other way around.
This is why the device flow is the right fit for tiny, screen-limited, one-way devices rather than full computers.
Safety built in
- The user code is short and temporary (it usually expires after a few minutes) — so it is useless to anyone who snoops after the setup.
- The device code is the device's private secret — long and kept secret, never shown on screen.
- The device never handles your password. Only the human's phone/laptop ever sees it, and only at the approval page.
- If the human clicks Deny, the server keeps saying "not yet" until the device code expires, and no token is ever issued.
When to use it — and when not to
- ✅ Perfect for: TVs, smart speakers, kiosks, CLIs, and any device that can show a short code but has no keyboard or browser.
- ❌ Not needed for: a normal web or mobile app (use the OpenID Connect (OIDC) authorization code flow), or a private machine talking only to another machine (use client credentials).
For a headless service with no screen at all — where you want it already approved before it starts — the standard device flow still expects a human to approve once. If that human approval should happen in advance (e.g. an operator sets up the device ahead of time), the device can be bootstrapped with a one-time code instead — see OAuth, OIDC & Duende IdentityModel for how that kiosk-style setup is designed in a .NET / IdentityServer world.