Category: OAuth & OIDC

Device Authorization Grant

Also known as: Device Flow, Device Authorization Flow, OAuth 2.0 Device Code Flow

Simply put

The Device Authorization Grant is a way for devices that have no browser or only limited input capabilities, such as smart TVs, streaming sticks, and command-line tools, to obtain access on a user's behalf. Instead of typing credentials on the device itself, the user completes sign-in on a separate device like a phone or computer, and the constrained device then receives an access token. This lets input-limited devices connect to services without requiring an awkward on-device login experience.

Formal definition

The Device Authorization Grant is an OAuth 2.0 authorization grant, specified in RFC 8628, designed for internet-connected devices that lack a browser or a suitable input method for user-agent-based authorization. In a typical flow, the device requests a device code and a user code from the authorization server, then instructs the user to visit a verification URI on a secondary device to enter the user code and complete authorization there. Meanwhile, the device polls the token endpoint until the user approves (or denies) the request, at which point it receives an access token (and, depending on configuration, a refresh token). As an OAuth 2.0 grant, it concerns delegated authorization and token issuance rather than user authentication; any authentication of the user occurs at the authorization server during the user-facing browser interaction, and obtaining an ID token for authentication would require pairing with OpenID Connect. Vendor implementations (for example, Microsoft Entra and Auth0) may vary in supported parameters and polling behavior.

Why it matters

Input-constrained devices, smart TVs, streaming sticks, hardware encoders, and command-line tools, create a real usability and security problem for delegated access. These devices often lack a browser or any practical way to type a username and password, and forcing on-device credential entry produces awkward, error-prone experiences that also risk exposing credentials on shared or semi-trusted hardware. The Device Authorization Grant, standardized as RFC 8628, addresses this by moving the user-facing authorization step to a secondary device such as a phone or computer that has a proper browser and input method.

Who it's relevant to

IAM and Application Architects

Architects designing access for smart TVs, streaming devices, hardware encoders, or CLI tools use the Device Authorization Grant to enable delegated access without on-device credential entry. They should treat it as an authorization grant and pair it with OpenID Connect where user authentication assurances (such as an ID token) are needed.

IAM Engineers and Developers

Engineers implementing the flow must handle the device-code/user-code exchange, direct users to the verification URI on a secondary device, and poll the token endpoint until approval or denial. Because polling behavior and supported parameters differ across providers such as Microsoft Entra and Auth0, engineers should test against their specific authorization server.

System Administrators

Administrators deploying input-constrained devices benefit from a sign-in experience that shifts credential entry to a phone or computer, avoiding awkward on-device logins. This keeps the user's primary credentials off the constrained device while still allowing it to receive access tokens on the user's behalf.

Inside Device Authorization Grant

Device Authorization Grant

An OAuth 2.0 grant type (defined in RFC 8628) designed for input-constrained devices, such as smart TVs, streaming boxes, CLI tools, and IoT hardware, that lack a browser or convenient text-entry capability. It lets the device obtain an access token by delegating the user's authorization step to a secondary device with richer input, such as a smartphone or laptop.

Device authorization endpoint

The endpoint on the authorization server where the device initiates the flow. In most deployments the device sends its client identifier (and scope) and receives a device_code, user_code, verification_uri, and related parameters in response.

Device code

An opaque identifier issued to the device that it uses when polling the token endpoint. It is not shown to the user and represents the pending authorization request on the authorization server.

User code

A short, human-readable code displayed on the constrained device that the user manually enters on the verification URI from their secondary device to associate that device with the authorization request.

Verification URI

The URL the user visits on a browser-capable device to authenticate and approve the request. RFC 8628 also allows a verification_uri_complete that embeds the user code, often rendered as a QR code to reduce manual entry.

Token endpoint polling

The mechanism by which the device repeatedly requests a token using the device_code and a grant_type of urn:ietf:params:oauth:grant-type:device_code. The authorization server responds with authorization_pending, slow_down, or, once the user approves, the requested tokens.

Polling interval and expiration

Parameters (typically interval and expires_in) that govern how often the device may poll and how long the device_code and user_code remain valid before the flow must be restarted.

Delegated authorization outcome

On successful user approval, the device receives tokens consistent with the OAuth 2.0 grant, typically an access token and optionally a refresh token; an ID token is issued only when the OpenID Connect layer is used to add authentication.

Common questions

Answers to the questions practitioners most commonly ask about Device Authorization Grant.

Does the Device Authorization Grant authenticate the user on the input-constrained device?

No. The Device Authorization Grant is an OAuth 2.0 flow, and OAuth 2.0 is a delegated authorization framework, not an authentication protocol. The flow lets a device obtain authorization (access to a resource) without conflating that with verifying who the user is. Any user authentication happens on the secondary device (typically a browser) at the authorization server, and if you need identity assertions about the user you would layer OpenID Connect on top rather than treat the grant itself as authentication.

Is the Device Authorization Grant only for devices that literally have no screen at all?

Not exactly. The grant is intended for input-constrained or browser-constrained devices, which is a broader category than screenless devices. A device may have a display capable of showing a verification URI and user code but still lack a keyboard or full browser for a conventional redirect-based flow. The defining constraint is limited input capability or the absence of a suitable browser, not the total absence of a display.

How does the device know when the user has completed authorization on the secondary device?

In most implementations the device polls the authorization server's token endpoint at an interval the server specifies. Until the user completes the flow, the server typically returns a pending-style error; the device continues polling until it receives tokens, an interval-adjustment response indicating it should slow down, or a terminal error such as expiry or denial. The exact error codes and behavior depend on the standard profile and the authorization server implementation.

What should implementers consider when displaying the user code and verification URI?

Considerations typically include making the user code easy to read and enter (character set and length affect usability and error rates), presenting the verification URI clearly, and, where the server supports it, offering a combined URI that embeds the code to reduce manual entry. Displaying a QR code for the verification URI is a common convenience where a display exists. Specific formats and whether a complete-with-code URI is offered depend on the authorization server.

How should refresh tokens be handled for devices using this grant?

If the authorization server issues a refresh token, the device can typically use it to obtain new access tokens without repeating the user-facing step, which matters for devices that stay provisioned long-term. Because such devices may be physically exposed, refresh token storage, rotation where supported, and revocation paths are important design points. Whether refresh tokens are issued and how they behave depends on the server configuration and the granted scopes.

What are the security risks specific to the user-code and polling mechanics?

Because the user enters a code out of band, phishing and social-engineering risks exist where an attacker induces a victim to authorize an attacker-controlled device by relaying a code. Mitigations discussed in the field include short code lifetimes, rate limiting and enforced polling intervals to limit brute forcing of codes, sufficient code entropy, and clear user-facing context about what is being authorized. The effectiveness of these mitigations depends on deployment and profile choices.

Common misconceptions

The Device Authorization Grant authenticates the user on the constrained device.

It is an OAuth 2.0 delegated authorization grant, not an authentication protocol. Any user authentication happens on the secondary browser-capable device at the verification URI, and identity assertions about the user require the OpenID Connect layer rather than OAuth 2.0 alone.

The user code and device code are interchangeable.

They serve distinct roles. The user_code is human-readable and entered by the user on the verification URI, while the device_code is an opaque value used only by the device when polling the token endpoint. They are not substitutes for one another.

The grant is only for IoT hardware.

While well suited to input-constrained IoT and smart TV scenarios, the grant is also commonly used for CLI tools and other clients that lack a convenient browser or keyboard, depending on the deployment.

Best practices

Present the verification URI clearly and, where supported, use verification_uri_complete rendered as a QR code to reduce user error from manual code entry.

Honor the authorization server's polling interval and back off on slow_down responses to avoid overloading the token endpoint.

Enforce short expiration windows on the device_code and user_code, and require the flow to restart cleanly once they expire.

Scope requested access to the minimum the device needs, and treat any issued refresh token as a sensitive long-lived credential that must be stored securely on the device.

Add OpenID Connect on top of the grant if the device use case actually requires authenticated user identity rather than only delegated authorization.

Validate returned tokens according to their type and the authorization server's configuration, remembering that a signed token is not necessarily an encrypted one.