Device Code Flow (OAuth 2.0 Device Authorization Grant)
What is Device Code Flow (OAuth 2.0 Device Authorization Grant)?
Device Code Flow (OAuth 2.0 Device Authorization Grant)An OAuth 2.0 grant (RFC 8628) where an input-constrained device (smart TV, CLI, IoT device) shows the user a code and a verification URL to authenticate on a second device — convenient for CLIs but a documented phishing vector.
The OAuth 2.0 Device Authorization Grant, specified in RFC 8628 and colloquially called the device code flow, lets a client without a usable browser (smart TVs, CLIs, kiosks, IoT devices) obtain user-delegated tokens by asking the user to authenticate on a separate device. The client requests a `device_code` and a short `user_code` from the IdP and displays the user_code plus a verification URL (e.g. `https://microsoft.com/devicelogin`); the user opens that URL on their phone or laptop, signs in, types the user_code, and consents. The IdP issues tokens to the original device. The flow is the basis for `gh auth login`, `az login --use-device-code`, Apple TV sign-in, Roku and Google TV pairing, and many CLI tools. It is also a documented phishing vector: an attacker can initiate a device code flow against a target tenant and send the user_code in a phishing message, tricking the victim into authenticating on a legitimate IdP page that issues tokens to the attacker (see Storm-2372). Defensive controls include Conditional Access policies that restrict the device code flow to specific apps or user groups, throttling, and user education.
● Examples
- 01
`gh auth login` prints a short user code and a URL; the user signs in on a laptop, enters the code, and the CLI receives tokens.
- 02
An Entra ID Conditional Access policy disables the device-code flow tenant-wide except for a tightly scoped CLI-user group.
● Frequently asked questions
What is Device Code Flow (OAuth 2.0 Device Authorization Grant)?
An OAuth 2.0 grant (RFC 8628) where an input-constrained device (smart TV, CLI, IoT device) shows the user a code and a verification URL to authenticate on a second device — convenient for CLIs but a documented phishing vector. It belongs to the Identity & Access category of cybersecurity.
What does Device Code Flow (OAuth 2.0 Device Authorization Grant) mean?
An OAuth 2.0 grant (RFC 8628) where an input-constrained device (smart TV, CLI, IoT device) shows the user a code and a verification URL to authenticate on a second device — convenient for CLIs but a documented phishing vector.
How does Device Code Flow (OAuth 2.0 Device Authorization Grant) work?
The OAuth 2.0 Device Authorization Grant, specified in RFC 8628 and colloquially called the device code flow, lets a client without a usable browser (smart TVs, CLIs, kiosks, IoT devices) obtain user-delegated tokens by asking the user to authenticate on a separate device. The client requests a `device_code` and a short `user_code` from the IdP and displays the user_code plus a verification URL (e.g. `https://microsoft.com/devicelogin`); the user opens that URL on their phone or laptop, signs in, types the user_code, and consents. The IdP issues tokens to the original device. The flow is the basis for `gh auth login`, `az login --use-device-code`, Apple TV sign-in, Roku and Google TV pairing, and many CLI tools. It is also a documented phishing vector: an attacker can initiate a device code flow against a target tenant and send the user_code in a phishing message, tricking the victim into authenticating on a legitimate IdP page that issues tokens to the attacker (see Storm-2372). Defensive controls include Conditional Access policies that restrict the device code flow to specific apps or user groups, throttling, and user education.
How do you defend against Device Code Flow (OAuth 2.0 Device Authorization Grant)?
Defences for Device Code Flow (OAuth 2.0 Device Authorization Grant) typically combine technical controls and operational practices, as detailed in the full definition above.
What are other names for Device Code Flow (OAuth 2.0 Device Authorization Grant)?
Common alternative names include: RFC 8628, OAuth 2.0 Device Authorization Grant.
● Related terms
- identity-access№ 839
OAuth 2.0
An open authorization framework that lets a resource owner grant a third-party application limited, scoped access to an API without sharing credentials.
- attacks№ 341
Device Code Phishing
An identity attack that abuses the OAuth 2.0 device authorization grant: the attacker starts a device-code flow and lures the victim into typing the resulting code on a legitimate login page, granting the attacker tokens for the victim's account.
- identity-access№ 852
OpenID Connect (OIDC)
An identity layer built on top of OAuth 2.0 that lets clients verify a user's identity and obtain basic profile information via signed ID tokens.
- identity-access№ 090
Authorization
The process of deciding what an already-authenticated identity is allowed to do — which resources, actions and conditions are permitted.
- identity-access№ 1162
Single Sign-On (SSO)
An authentication scheme that lets a user sign in once at a trusted identity provider and then access many applications without re-entering credentials.
- identity-access№ 928
PKCE (Proof Key for Code Exchange)
An OAuth 2.0 extension (RFC 7636) that binds an authorization-code redemption to a one-time secret created by the client, neutralizing authorization-code interception attacks on public and confidential clients alike.