Device Authorization Grant: Solving OAuth for screens without keyboards

When building modern applications, OAuth 2.0 is the go-to standard for delegating access in a secure and user-friendly way. But what happens when your app lives on a smart TV, a gaming console, or an IoT device—places where typing is either painful or impossible?

This is where the Device Authorization Grant (also known as Device Code Flow) comes into play. Defined in RFC 8628, this flow is purpose-built for devices that don’t have a browser or keyboard, enabling seamless user login by deferring the authentication step to a second device.

Let’s explore why we need this flow, what problem it solves, and how to implement it.

The problem: OAuth on input-constrained devices

Most OAuth 2.0 flows assume the client has access to a browser and the ability to enter credentials. For example, in the Authorization Code flow, the user is redirected to a browser, logs in, and then is redirected back to the application with an authorization code.

But what about devices like:

• A smart TV remote with only arrow keys
• A console game controller
• A CLI application in a headless server environment
• An IoT sensor with a 2-line display

None of these can open a browser window, display a login screen, or let users type in email, password, and 2FA codes.

Trying to retrofit standard OAuth flows in these environments results in frustrating UX or security vulnerabilities.

The solution: Device Authorization Grant

The Device Code Flow offloads the authentication process to a secondary device (e.g., your phone or laptop). Here's how it works:

1. The device makes a POST request to the authorization server with its client ID and scope, asking for a user verification code.
2. The Authorization Server responds with:‍
   
   • device_code: A code for backend polling.‍
   • user_code: A short code the user will type.‍
   • verification_uri: A URL the user should visit.‍
   • expires_inThe lifetime in seconds of the device_code and user_code.‍
   • intervalThe minimum amount of time in seconds that the client should wait between polling requests to the token endpoint.  If no value is provided, clients must use 5 as the default.
3. The device instructs the user to “Go to  and enter code: ABCD_EFGH”. On their phone or laptop, the user logs in, grants permission, and confirms.
4. Meanwhile, the device polls the token endpoint using device_code. When the user authorizes, it gets back an access token.
5. Now the device can act on behalf of the user, just like any other OAuth flow.

Example

Let’s see a simplified example in pseudocode:

	
# 1. Device requests codes
POST /device_authorization HTTP/1.1
client_id=abc123&scope=example_scope

# 2. Server response
{
  device_code: "abcxyz...",
  user_code: "ABCD-EFGH",
  verification_uri: "https://example.com/device",
  expires_in: 900,
  interval: 5
}

# 3. Show user prompt
"Visit https://example.com/device and enter code ABCD-EFGH"

# 4. Poll for token
POST /oauth/token
grant_type=device_code
device_code=abcxyz...
	

If user authorizes, the token response is returned. If not, you’ll get an error.

Security considerations

Despite its simplicity, the Device Code Flow includes several key security features:

• Short-lived codes: Device and user codes expire quickly.
• Rate-limited polling: Helps prevent token endpoint overload.
• Explicit user consent: Prevents silent or background logins.
• Phishing resistance: Users always enter codes on trusted domains.

However, you should:

• Enforce strong client authentication if applicable.
• Avoid overly long polling intervals (or being too aggressive).
• Handle authorization_pending, slow_down, and expired_token errors gracefully.

The danger of device code phishing

Since August 2024, a sophisticated phishing campaign—tracked as Storm-2372—has been actively exploiting the device code authorization flow to gain unauthorized access to user accounts. This threat has been attributed to Russian state-linked actors, and it's particularly notable because it doesn’t rely on traditional email phishing or malicious links.Instead, the attackers:

• Trick users into visiting legitimate device authorization URLs (e.g., login.microsoft.com/devicelogin).
• Provide users with maliciously generated user codes that tie back to attacker-controlled device codes.
• Once users enter the code and authenticate, attackers obtain valid access tokens—without needing to harvest passwords or bypass MFA.

This campaign underscores a critical weakness in the flow: the assumption that the user code entry on a trusted domain (e.g., Microsoft, Google) ensures safety—when in fact, the source of the user code itself may be malicious.

To defend against this class of attacks:

• Educate users that they should only enter user codes they generated themselves, not ones sent via email, SMS, or chat.
• Restrict or monitor device code usage to high-trust applications and known endpoints.
• Use conditional access and anomaly detection to flag suspicious device logins.
• Monitor token usage patterns for tokens issued via device code flow.

Final thoughts

The Device Authorization Grant Flow elegantly solves the problem of secure user authentication on devices that lack traditional input methods. It’s a practical, standards-based solution that enables login on smart TVs, CLI tools, IoT platforms, and more—without compromising usability.

However, as the Storm-2372 phishing campaign shows, even well-designed flows can be exploited if not implemented and monitored carefully. Developers must understand not just how the flow works, but how malicious actors may abuse its user experience patterns, especially by tricking users into entering codes tied to attacker-controlled sessions.

When using the Device Flow:

• Never assume implicit safety just because users land on a trusted domain.
• Educate users and build contextual clues into your auth UX.
• Monitor access tokens and authentication patterns aggressively.

In the right contexts—and with the right safeguards—the Device Code Flow remains a powerful tool in your OAuth toolkit.