Device Authorization Flow

This flow is explicitly engineered for headless or input-constrained hardware where entering a username and password is impractical or impossible. Target devices include:

• Smart TVs and media streamers
• Internet of Things (IoT) appliances
• Gaming consoles
• Command-line tools
• Printers and embedded systems

The protocol shifts the complex authentication interaction to a secondary device with a full browser, solving the primary device's user interface limitations.

The core mechanism involves a two-part handoff. The authorization server provides two pieces of information to the device:

• User Code: A short, human-readable code (e.g., BDWD-HQPK).
• Verification URI: A website address (e.g., https://example.com/device).

The device displays this information to the user. The user must then navigate to the Verification URI on a secondary device (like their phone), enter the User Code, and complete the standard OAuth 2.0 consent screen. This decouples the authentication ceremony from the constrained device.

After initiating the flow, the device client does not receive tokens directly. Instead, it must repeatedly poll the authorization server's token endpoint. The client sends its device_code and client_id in these polling requests.

The server responds with a pending status until the user completes the authorization on the secondary device. Upon successful user consent, the next poll returns the access token and optionally a refresh token. This polling model is necessary because the constrained device cannot receive an HTTP redirect.

Device and user codes have significantly longer expiration times compared to standard authorization codes. Typical specifications advise:

• User Code Expiration: 15-30 minutes, giving the user ample time to switch devices.
• Device Code Expiration: Can be longer, often matching the maximum user session time.

The polling interval is also dictated by the server, often via a interval parameter in the initial response (e.g., 5 seconds). Clients must honor this interval to avoid being rate-limited.

While convenient, the flow introduces specific security vectors that must be mitigated:

• User Code Entropy: Codes must be sufficiently random and long enough to resist brute-force guessing.
• Short Verification URIs: The displayed URL should be short and easy to type. Using a static, well-known domain with a short path is common.
• Limited Activation Scope: The issued access token should be scoped specifically to the device and its intended use, following the principle of least privilege.
• User Verification: The consent screen on the secondary device should clearly display the requesting device's name and the permissions being granted.

The standard OAuth 2.0 grant for server-side web applications. The client redirects the user to an authorization server, which returns an authorization code to a pre-registered redirect URI. The client then exchanges this code for an access token securely on the backend.

• Primary Use Case: Traditional web applications with a server-side component.
• Key Security Feature: The access token is never exposed to the user's browser.
• Contrast with Device Flow: Designed for user-facing applications where the user can directly interact with a browser on the same device.

An extension to the Authorization Code flow designed to secure public clients—like mobile and single-page apps—that cannot store a client secret. The client creates a code verifier and a derived code challenge. The authorization server binds the issued authorization code to this challenge, preventing interception attacks.

• Mitigates Threat: Authorization code interception.
• Essential For: Native mobile apps and JavaScript-based SPAs.
• Relation to Device Flow: Both are designed for clients where secret storage is insecure, but PKCE assumes the user can interact with a browser on the same device.

An OAuth 2.0 grant for machine-to-machine (M2M) communication where the client acts on its own behalf, not a user's. The client authenticates with its client ID and secret (or certificate) to directly obtain an access token for its own resources.

• Primary Use Case: Service account access, backend API communication.
• No User Involvement: The entire flow occurs between the client and authorization server.
• Contrast with Device Flow: Represents the opposite end of the spectrum—no user interaction versus requiring user interaction on a secondary device.

A legacy OAuth 2.0 grant where the client application collects the user's username and password and exchanges them directly for an access token. This flow is highly discouraged due to security risks, as it requires the user to trust the client with their credentials.

• High Risk: Client sees plaintext passwords, increasing attack surface.
• Limited Use: Only for highly-trusted first-party clients (e.g., a company's own mobile app).
• Contrast with Device Flow: Device Flow is explicitly designed for scenarios where entering a password on the device is infeasible or insecure, avoiding credential exposure to the constrained device.

A long-lived credential issued alongside an access token that allows a client to obtain new access tokens without requiring the user to re-authenticate. Refresh tokens are a core component of OAuth 2.0 that enable persistent access within a session.

• Lifetime Management: Enables short-lived access tokens for security while maintaining user session.
• Security Consideration: Must be stored securely by the client; their issuance is often restricted to confidential clients.
• In Device Flow: The device client can use a refresh token (if granted) to poll for new access tokens, maintaining access after the initial user authorization.

The core interactive components of the Device Authorization Flow. After initiation, the authorization server returns a short, human-readable user code (e.g., ABCD-EFGH) and a verification URI (often a short URL).

• User Experience: The device displays this code and URI. The user navigates to the URI on a secondary device (like a smartphone), enters the code, and authenticates.
• Polling Mechanism: While the user completes this step, the constrained device polls the authorization server's token endpoint until authorization is granted or denied.
• Design Purpose: Bridges the gap between an input-constrained device and a full authentication interface.