Device Code Flow (OAuth 2.0 Device Authorization Grant).

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; meanwhile the device polls the token endpoint (honouring the interval and backing off on slow_down) until the IdP issues tokens. It underpins gh auth login, az login --use-device-code, Apple TV sign-in, and Roku/Google TV pairing.

The same design is a potent phishing vector, because the user authenticates on a legitimate IdP page — so there is no lookalike domain to spot. An attacker starts a device code flow against the target tenant and relays the fresh user_code to the victim in a time-pressured lure; when the victim enters it, tokens flow to the attacker. Microsoft's February 2025 report on Storm-2372, a Russia-aligned actor active since August 2024, documented exactly this: Teams-meeting lures led targets across government, defense, and NGOs to enter attacker-generated codes, after which the actor used the tokens to harvest mail via Microsoft Graph. Defences include Conditional Access policies that restrict or disable the device code flow except for specific apps and user groups, short token lifetimes, and user education that a device code should only ever be entered for a sign-in the user personally started.

sequenceDiagram
  participant D as Device (CLI/TV)
  participant I as Identity Provider
  participant U as User (phone/laptop)
  D->>I: Request device_code + user_code
  I-->>D: device_code, user_code, verification_uri
  D-->>U: Show "Go to URL and enter CODE"
  loop Poll (respect interval / slow_down)
    D->>I: Poll token endpoint with device_code
    I-->>D: authorization_pending
  end
  U->>I: Open verification_uri, sign in, enter user_code, consent
  I-->>D: Access + refresh tokens
  Note over U,I: Phishing risk: attacker relays its own user_code<br/>so tokens are issued to the attacker