Cybersecurity glossary
What is the Device Authorization Grant?
Learn what the OAuth device authorization grant is, how TVs and CLIs log in with user codes, security risks of device flows, and hardening practices for device code authentication.
Definition
The device authorization grant (device code flow) is an OAuth 2.0 extension that lets input-constrained devices obtain user-authorized tokens by showing a user code and verification URL that the user completes on a separate browser-capable device.
Why constrained devices need a special grant
Smart TVs and headless CLIs often cannot complete a normal redirect-based login. The device authorization grant splits the work: the device waits with a code, while the user authenticates on a phone or laptop that has a real keyboard and browser.
It improves usability for awkward screens—and introduces phishing and code-guessing risks that must be designed for.
How the device code flow works
Device requests codes
The client calls the device authorization endpoint and receives a device code, user code, verification URI, and expiry.
User is prompted
The device displays the user code and URL (or QR linking to the verification page).
User authorizes elsewhere
On another device, the user signs in, enters the user code, and consents to scopes.
Device polls for tokens
Using the device code, the client polls the token endpoint until authorized, denied, or expired.
Tokens issued
Access and optional refresh tokens are returned to the device client for API use.
UX pieces users must trust
Verification URI
Must be HTTPS on a recognizable, stable host owned by the authorization server.
User code
Short enough to type, strong enough to resist guessing within the lifetime.
Client identity
Consent screens should clearly name the TV app, CLI, or device requesting access.
Scope clarity
Users should see exactly which permissions the living-room device will receive.
Expiry countdown
Codes should die quickly so abandoned displays stop being useful to attackers.
Denial path
Users need an obvious way to reject unexpected device link requests.
Threats and mitigations
| Threat | Detail | Mitigation |
|---|---|---|
| User-code guessing | Attacker tries codes while polling | Entropy, rate limits, lockouts, short TTL |
| Verification phishing | Fake site harvests codes/logins | Trusted domain education, phishing-resistant IdP MFA |
| Wrong-device approval | User authorizes attacker’s session | Show client name, location hints, confirm codes carefully |
| Over-broad device tokens | TV receives admin-capable scopes | Minimal scopes; separate privileged clients |
Implementation checklist
- Prefer authorization code with PKCE when the client can run a browser or loopback redirect.
- Generate user codes with adequate entropy and enforce aggressive rate limiting.
- Expire device and user codes quickly; stop polling after timeout.
- Display a clear client name and requested scopes on the approval screen.
- Bind successful authorization to the specific device client instance when possible.
- Issue least-privilege tokens; avoid reusing powerful refresh tokens on shared TVs.
- Monitor bursts of device_code grants and failed user-code attempts.
- Document user guidance: only approve codes you initiated and verify the URL.
The practical takeaway
The device authorization grant lets limited-input devices obtain user-approved OAuth tokens through a second screen. It is powerful for CLIs and TVs, and attractive to phishers who want users to type codes into the wrong place.
Keep codes short-lived and hard to guess, make consent unmistakable, minimize scopes, and use a normal redirect grant whenever the device can support one.
Related security terms
OAuth 2.0
Base framework extended by the device authorization grant.
Authorization Code
Preferred interactive grant when the device can complete a redirect safely.
OAuth Client
The device or CLI registered to start device authorization.
Refresh Token
Often issued after successful device authorization for ongoing access.
Proof Key for Code Exchange (PKCE)
Used with authorization code when a redirect-based flow is available instead.
Frequently asked questions
What is the device authorization grant in simple terms?
Your TV or CLI shows a short code and a link. You open that link on your phone or laptop, sign in, and the TV/CLI receives tokens after polling the authorization server.
Which RFC defines this flow?
RFC 8628 defines the OAuth 2.0 device authorization grant.
When should you use device flow instead of authorization code?
When the client cannot conveniently host a redirect URI or browser—smart TVs, projectors, some CLIs, and IoT consoles with limited input.
What is a user code?
A short, human-enterable code displayed by the device that the user types on the verification page to link their login session to that device.
What are the main security risks?
User-code guessing, phishing of verification URLs, long polling windows, overly broad scopes, and users approving the wrong device if codes are leaked or shoulder-surfed.
How do you harden device authorization?
Use high-entropy codes with rate limits, short expiry, clear client identity on consent screens, minimal scopes, and prefer authorization code with PKCE when a browser is available.
Can attackers phish device flows?
Yes. Fake prompts can trick users into entering codes on attacker-controlled sessions. Educate users to verify domain and client name, and monitor anomalous device grants.
References
Explore authoritative guidance and frameworks related to device authorization grant.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.