The Device Authorization Grant in OAuth 2.0
How a smart TV, game console, or command-line tool with no keyboard-friendly browser can still ask for — and safely receive — your permission.
Picture setting up a new streaming app on your television. The screen shows a short code, something like “WXYZ-1234,” along with an instruction: “go to a website on your phone or computer and enter this code.” You pull out your phone, type the code, log in, and a moment later the TV simply lights up, fully connected, without you ever having typed a single password using your remote control. That entire experience — code on one screen, login on a second, better-suited screen — is not a clever trick invented by the streaming company. It is a standardized part of OAuth 2.0 called the Device Authorization Grant, and this tutorial explains exactly how it works, piece by piece.
1The Problem: Devices Without a Good Keyboard
To understand why this grant type exists, first understand the everyday inconvenience it was built to remove.
The Authorization Code Grant, the most common way apps ask for your permission, assumes something important: that the person approving the request has a real web browser and a comfortable way to type, usually a keyboard or a touchscreen. That assumption holds for laptops and phones, but it breaks down completely for a large category of everyday devices — smart TVs, streaming boxes, game consoles, smart speakers, printers, and command-line developer tools running inside a terminal window. These devices either have no browser at all, or they have one that is painfully slow to use with a remote control’s directional pad.
Imagine trying to type your email password on a television remote, clicking one letter at a time as the cursor crawls across an on-screen keyboard. It is technically possible, the same way it is technically possible to eat soup with a fork. The Device Authorization Grant simply recognizes that some tools are the wrong tools for the job, and lets you finish the task on a device better suited for it instead.
Rather than forcing an awkward on-screen keyboard experience, or worse, encouraging people to type their real password directly into a device that cannot securely display or store it, the OAuth working group designed a grant specifically for this situation. Its core idea is simple: let the input-constrained device display a short code and a website address, and let the actual login happen on a second device the user already trusts and finds comfortable — almost always their own phone or laptop.
This pattern is formally called the Device Authorization Grant, though many engineers casually call it the “device code flow,” because the short code shown on the constrained device is its most visible ingredient.
2Meet the Participants
This flow involves one more moving part than a typical OAuth conversation: two separate screens working together.
Device (the Client)
The input-constrained gadget — a smart TV, a game console, a command-line tool — that wants access but cannot comfortably run a browser-based login itself.
User
The human sitting in front of the device, who will finish the approval process on a separate, more convenient device such as a phone.
Secondary Browser
Any ordinary web browser the user already has handy — typically on their phone or laptop — used only to visit a verification page and type the short code.
Authorization Server
The service that generates the codes, shows the verification and consent page in the secondary browser, and eventually hands the device its access token.
It works like checking into a conference using a self-service kiosk that has no keyboard, only a screen. The kiosk shows you a claim number and tells you to visit the registration desk with your ID. You walk to the desk, show your ID, mention the claim number, and the kiosk across the room instantly prints your badge — you never touched a keyboard on the kiosk itself.
3The Building Blocks
A few new terms appear in this grant that do not show up in the more common browser-based flow.
Device Code
A long, random, hard-to-guess string the device keeps privately to itself, used behind the scenes to repeatedly ask “has the user approved me yet?”
User Code
A short, easy-to-type, human-friendly code, often shown in large letters on the device’s screen, that the person types into the secondary browser.
Verification URI
The simple web address the device displays and asks the user to visit on another device, where the user code is entered.
Polling Interval
The number of seconds the device is told to wait between each check-in with the Authorization Server, so it does not overwhelm it with constant requests.
Expiration Time
A countdown, usually a matter of minutes, after which an unused user code and device code both become invalid and the process must restart.
Verification URI Complete
An optional convenience: a single web address with the user code already built in, often shown as a scannable QR code, so the user does not need to type anything at all.
Notice the deliberate size difference between the two codes. The device code is long and random precisely because it must be difficult for anyone to guess or brute-force. The user code is short and simple on purpose, because a human being has to read it off a screen and type it correctly, possibly from across a room, on a different device.
4The Flow, Step by Step
This chapter walks through the entire process from the moment the app is opened on the device to the moment it becomes fully connected.
Device Requests a Code Pair
The moment the app launches on the TV, console, or terminal, it silently contacts the Authorization Server’s device endpoint and asks for a fresh device code and user code.
Authorization Server Issues Both Codes
The server responds with the long device code, the short user code, the verification web address, a polling interval, and an expiration time — typically all within a second or two.
Device Displays Instructions
The screen shows the short user code in large, easy-to-read text, along with the plain verification address, and often a QR code as a shortcut for phones with a camera.
Device Quietly Starts Polling
In the background, without the user needing to do anything, the device begins repeatedly asking the Authorization Server, at the given interval, “has this device code been approved yet?”
User Opens the Verification Page Elsewhere
On their phone or laptop, the user visits the verification address shown on the device, and either types the user code by hand or scans the QR code, which fills it in automatically.
User Logs In and Confirms
The user logs into their account as usual, on a full-sized, keyboard-friendly browser, and sees a consent screen confirming which device and what permissions are being requested before approving.
Authorization Server Marks the Device Code as Approved
Behind the scenes, the moment the user clicks Allow, the Authorization Server links that approval to the matching device code, ready for the next poll to discover it.
Device’s Next Poll Receives Tokens
On its next scheduled check-in, instead of the usual “still waiting” response, the device receives an access token and, often, a refresh token, and immediately stops polling.
Device Becomes Fully Connected
The screen updates, typically with a friendly confirmation message, and the device can now call protected resources using the access token, exactly as any other OAuth client would.
At no point during this entire flow does the smart TV, console, or terminal ever see the user’s password. All of the sensitive login work happens on the secondary browser, which the user already trusts and finds far easier to use.
5Seeing the Whole Flow as a Diagram
The two-screen, two-timeline nature of this flow becomes much clearer as a picture.
sequenceDiagram
participant D as Device (TV / Console / CLI)
participant A as Authorization Server
participant P as User's Phone / Laptop
D->>A: 1. Request device code + user code
A->>D: 2. Return codes, verification URL, poll interval
D->>D: 3. Display user code and instructions
loop Every few seconds
D->>A: 4. Poll: "Is this device code approved?"
A->>D: 5. "Still waiting..."
end
P->>A: 6. Visit verification page, enter user code
A->>P: 7. Show login + consent screen
P->>A: 8. User approves access
D->>A: 9. Poll again
A->>D: 10. Return access token + refresh token
The most important thing to notice in this diagram is that the device and the user’s phone never talk to each other directly at all. Every single message passes through the Authorization Server, which acts as the coordinator linking “a device is waiting for approval” with “a user just approved something.” The device does not even know what the user is doing on their phone; it simply keeps asking, patiently, until the answer changes from “still waiting” to “here are your tokens.”
6Why Not Just Use the Regular Authorization Code Grant?
It is worth directly comparing this grant to the more familiar browser-redirect flow, to see exactly what problem it solves.
Authorization Code Grant on a TV
- Requires an on-screen web browser capable of rendering a full login page, which many TVs either lack or implement poorly.
- Typing an email address and password using a remote control’s arrow keys is slow and error-prone.
- Redirect URIs are awkward to handle on devices that are not running a conventional web server.
Device Authorization Grant on a TV
- Requires only the ability to display text and make simple outbound network requests — no browser needed on the TV at all.
- All typing happens on a phone or laptop, using a normal keyboard or touchscreen the user already knows well.
- There is no redirect step for the constrained device to manage; it simply polls until it receives an answer.
7Security Considerations
Because this flow deliberately shows a code on a shared or public screen, it comes with its own specific set of risks to guard against.
User Code Guessing
Because the user code is short, an attacker could try guessing codes at random. Short expiration times and rate-limiting on guesses keep this impractical.
Session Hijacking via Phishing
An attacker could display their own fraudulent code somewhere public and trick a victim into approving access to the attacker’s device instead of their own.
Excessive Polling
A poorly built device that ignores the given interval and polls too fast could be mistaken for an attack and get temporarily blocked by the Authorization Server.
Leftover Approved Sessions
A device left connected on a shared or public television, such as in a hotel room, continues to hold a valid token until it is manually revoked or expires.
The consent screen on the secondary device should always clearly name which device or application is requesting access, so the user can catch a mismatch — such as approving what they believe is their own living-room TV when it is actually an unrelated device — before clicking Allow.
Because of the shorter, guessable-length user code, Authorization Servers deliberately keep these codes valid for only a short window, commonly somewhere between five and fifteen minutes, and they rate-limit how many incorrect code attempts can be made in that time. This keeps the convenience of a short code without meaningfully weakening the overall security of the exchange.
8Advantages and Trade-offs
Advantages
- No password is ever typed on the constrained device itself.
- Works on devices with no browser at all, including many command-line tools and embedded systems.
- The user gets to log in on a device and keyboard they are already comfortable with.
- A QR code shortcut can make the whole process nearly instant for phones with a camera.
- The same underlying token model and refresh-token behavior as the Authorization Code Grant applies afterward.
Disadvantages / Trade-offs
- It requires the user to own or have access to a second, more capable device — a rare but real limitation.
- The repeated polling adds a small amount of ongoing network chatter until approval happens or the code expires.
- Short, human-typeable codes are inherently a little less resistant to blind-guessing than long random strings, which is why short expiration and rate-limiting are essential.
- It is a poor fit for scenarios where the same person is already sitting at a full browser, since the extra “look at another screen” step becomes unnecessary friction.
These trade-offs explain why the Device Authorization Grant is used specifically for input-constrained devices, and essentially never for ordinary websites or mobile apps, which are already perfectly capable of running the standard Authorization Code Grant directly.
9Best Practices and Common Mistakes
Problem
Polling the Authorization Server faster than the interval it explicitly provided, in an attempt to “feel” more responsive to the user.
Why It’s Harmful
Ignoring the given interval can trigger rate-limiting or temporary blocking, ironically making the connection process slower or causing it to fail entirely.
Correct Approach
Always respect the server-provided polling interval, and back off further if the server explicitly signals that polling is happening too quickly.
Problem
Leaving the user code and verification instructions on screen indefinitely, long after the code has actually expired.
Why It’s Harmful
A user who tries to complete an already-expired code wastes time and becomes confused about why nothing happens after they approve it.
Correct Approach
Visibly count down toward expiration on the device’s screen, and automatically request a brand-new code pair once the old one lapses.
Problem
Failing to clearly identify the requesting device or application by name on the consent screen shown on the secondary device.
Why It’s Harmful
Without a clear device name, a user cannot easily tell whether they are approving their own living-room television or a different, unfamiliar device using a similar-looking code.
Correct Approach
Always show a specific, recognizable application or device name and requested scopes on the approval screen, not just a generic “approve access” message.
10Real-World Examples You Have Probably Already Used
Streaming Apps on Smart TVs
Video streaming services almost universally use this exact flow to connect a television app to your existing account, showing a short code and asking you to finish setup on a phone or computer.
Game Consoles
Signing into a game console’s account from the console itself, using a controller instead of a keyboard, commonly relies on this same code-and-second-device pattern.
Command-Line Developer Tools
Many developer command-line tools that need to connect to a cloud account print a short code and a web address directly into the terminal, then wait quietly until the developer finishes logging in in their regular browser.
Smart Speakers and IoT Devices
Voice assistants and other connected home devices, which often lack any screen-based keyboard at all, frequently use this flow, sometimes paired with a companion mobile app that scans a QR code shown briefly on a small display.
11How It Compares to Other OAuth 2.0 Grant Types
| Grant Type | Typical Use Case | Needs a Browser on the Client Device? | Current Recommendation |
|---|---|---|---|
| Device Authorization | Smart TVs, consoles, CLI tools, input-constrained devices | No — uses a second device instead | Recommended for input-constrained devices |
| Authorization Code (+ PKCE) | Regular web apps, mobile apps, single-page apps | Yes, on the same device | Recommended default when a browser is available |
| Client Credentials | Server-to-server calls with no individual user involved | No | Recommended for machine-to-machine access |
| Implicit | Historically used for single-page apps | Yes | Deprecated; replaced by Authorization Code with PKCE |
The clearest way to remember when to reach for the Device Authorization Grant is to ask a single question: does the device in front of the user have a comfortable way to type and browse the web? If the answer is no, this grant is very likely the right tool, and if the answer is yes, the standard Authorization Code Grant is almost always the better default.
12Frequently Asked Questions
Yes. The device must be able to reach the Authorization Server for its periodic polling requests, even though it is not doing anything visible during that waiting period beyond showing the code.
Once the user code and device code expire, usually within several minutes, the Authorization Server simply starts rejecting further polls with an expiration message, and the device must request a brand-new pair of codes to try again.
No. A user code is tied to exactly one pending device authorization request, and once it has been approved or denied once, it cannot be reused for a different outcome.
Not meaningfully, because the short code’s weaknesses are offset by a short expiration window and rate-limited guessing attempts, while the actual sensitive login and token issuance still happen through the same protected mechanisms as any other OAuth flow.
The device has no way to receive an incoming message on its own, since it is not running a web server and cannot accept a redirect the way a browser can, so polling is the practical way for it to find out when approval has happened.
13Summary and Key Takeaways
The Device Authorization Grant solves a very specific, very human problem: some devices are simply the wrong shape for typing a password. Rather than forcing an awkward workaround, it splits the experience across two screens — a short, glanceable code on the constrained device, and the actual login and consent on a phone or laptop the user already finds comfortable. Behind that simple experience sits a careful design involving a long, private device code, a short, human-friendly user code, and a patient polling loop that waits for approval without ever exposing a password to the constrained device itself. Once you recognize this “code on one screen, login on another” pattern, you will spot it on nearly every television, console, and command-line tool you connect to your accounts.
Key Takeaways
- Built for input-constrained devices — TVs, consoles, and CLI tools that lack a comfortable browser or keyboard.
- Two codes, two purposes — a long device code kept private, and a short user code meant to be read and typed by a human.
- Login happens on a second, trusted device — the constrained device never sees a password.
- Polling replaces redirects — the device repeatedly checks in rather than waiting for an incoming callback it cannot receive.
- Short codes need short lifetimes — brief expiration windows and rate-limiting keep guessing attacks impractical.
- Not a general-purpose replacement — for ordinary web and mobile apps with a real browser, the Authorization Code Grant remains the right default.