Some clients cannot host a browser. A command line tool on a server, a television application, a device with four buttons and no keyboard. The authorization code flow assumes a redirect, and there is nothing to redirect.
The device authorization flow solves it by splitting the ceremony across two screens. The device asks your authorisation server for a pair of codes, shows the human-readable one along with a short URL, and then polls while the person completes the approval on a phone or laptop that does have a browser.
The mechanics, and the polite way to poll
The device posts to the device authorisation endpoint and receives a device code it keeps to itself, a user code it displays, a verification URL, an expiry and a polling interval. It then calls the token endpoint repeatedly with the device code until the person approves, at which point it receives tokens as usual.
The polling has rules and they matter. Wait the interval the server gave you, treat authorization_pending as normal rather than as an error, and back off when told to slow down. A client that polls tightly will be rate limited, and the failure surfaces to the user as a device that will not connect for reasons nobody can see.
- Respect the returned interval; increase it when the server says to slow down
- authorization_pending means keep waiting; expired_token means start over
- Give the user code a short lifetime — minutes, not an afternoon
- Use an unambiguous alphabet: no characters that look like other characters
- Rate limit and lock out guessing against the verification endpoint
The social engineering problem
The flow's convenience is also its weakness. Nothing binds the person approving the request to the device that started it. Somebody can begin the flow on their own device, obtain a code, and persuade a victim to enter it — over the phone, in a chat message, in an email that looks like an IT request. The victim approves what appears to be a routine sign-in and hands over a session to a machine they have never seen.
There is no protocol fix, so the mitigations are in the interface. Show what is being authorised in concrete terms: the client name, the scope in plain words, the address the request came from, and where possible an identifier the person can compare with what their own screen displays. Then require a deliberate confirmation rather than a single button that says continue.
Nothing in the protocol binds the person approving to the device that asked. The interface has to do it.
Keep it scoped and revocable
Devices authorised this way tend to be long-lived — a build server, a set-top box — which means the credential they hold outlives the attention anybody pays to it. Issue narrow scopes, prefer a refreshable short access token over a long-lived one, and make sure a revoked grant stops working immediately rather than at the next expiry.
List them somewhere a person can see. A page showing every device holding a grant, when it last called, and a button to revoke it is how somebody discovers the television they gave away two years ago still has access.
Everything here, already built
Sign-in, enterprise SSO, directory provisioning, roles and an audit trail behind one API. Start with the quickstart and have a working sign-in this afternoon.