OAuth device authorization grant: when to use it and when not to

The OAuth device authorization grant (RFC 8628) lets a device that cannot run a browser get user approval on a second device. It suits TVs, consoles, printers and some command line tools. It is risky for general sign in because an attacker can start a flow and talk a victim into approving it.

How the flow works

1. The device posts its client_id and scope to the device authorization endpoint.
2. The server returns a device_code, a short user_code, a verification_uri, an expires_in, and optionally an interval.
3. The device shows the code and URL.
4. The user opens the URL on a phone or laptop, signs in, enters the code and approves.
5. Meanwhile the device polls the token endpoint with the device code.

The device code is never shown to the user. The user code is short so people can type it.

Polling rules

The default minimum interval is 5 seconds. The server may answer with:

• authorization_pending: keep polling, respecting the interval.
• slow_down: increase the interval by 5 seconds for this and later requests.
• access_denied: the user said no, stop.
• expired_token: the code expired, stop and start over only after a user action.

On connection timeouts, back off, and the RFC recommends exponential backoff.

When it is a good fit

• Input constrained hardware with a screen but no keyboard.
• Command line tools on a server or inside a container with no browser.
• Cases where you control the verification page and can show clear context to the user.

If a device has a browser, use the authorization code flow with PKCE instead.

The phishing problem

RFC 8628 describes remote phishing: an attacker starts a flow on their own device, then convinces a victim to open the verification page and enter the code. If the victim approves, the attacker's device receives tokens for the victim's account. The user did not hand over a password, and may not know what they approved.

Mitigations the RFC lists include telling users they are authorizing a device, asking them to confirm the device is in their possession, and showing device details or the code on both screens.

Other points to design for:

• User code guessing. Rate limit attempts and keep the code lifetime short.
• Device code guessing. Use high entropy, since users never type it.
• Shoulder surfing. Someone watching the screen could finish authorization first. Consider where the code is displayed.

If you run an identity provider

Consider restricting the device grant to the clients that need it, rather than leaving it on for everyone. Show the client name and requested scope on the approval page. Log and review device approvals.

Quick check

Sources

• RFC 8628, OAuth 2.0 Device Authorization Grant

Last reviewed: 19 October 2026.