ndovuoauth2

The device flow, step by stepin progressruns in your browser · zero network calls - the authorization server is simulated
user_code····-····
verification_uri·
expires (virtual)·
poll stateno session yet

01 · the device asks for codes

A device with a screen but no keyboard cannot render your login page, so it asks for a code pair: one machine-readable, one human-typeable (§3.1).

client_id
1406020730the RFC §3.1 example client - devices are public clients: they identify, they do not authenticate
scope
example_scopewhat the device wants to do on your behalf
endpoint
POST server.example.com/device_authorizationa separate endpoint from /authorize - TLS is a MUST
wire - everything that movednothing yet
nothing yet - start the flow and every request lands here

RFC 8628 · DEVICE AUTHORIZATION GRANT

The device console

0:00 / 5:08Read along

Run the full device authorization grant (RFC 8628) in your browser: the TV shows a code, your phone approves, the device polls - with the exact slow_down rule, expiry, brute-force lockout, and the remote-phishing twist.

updated October 29, 2026The flow, on the wire

This is the whole device authorization grant, and you play both ends: the streaming stick that shows a code, and the phone that approves it. The authorization server issimulated - every real device endpoint either blocks browser calls (CORS) or would demand an embedded client secret and real consent, and none of them speak the RFC's exact grammar. So this console runs the RFC's own published example values, verbatim, and every check a real AS runs is the check this mock runs. The wire drawer under the console records everything that moves on the back channel; three buttons are deliberately dangerous. And #scenario=phish-yes drops you straight into the RFC's remote-phishing demo: the attacker's SMS has just arrived, their code pre-filled in the link.

What to take away
  • Polling is the protocol here: the client waits at least interval seconds (5 by default) between polls, forever.
  • slow_down is cumulative and permanent - +5 seconds per violation, for this and every later request, until the session ends.
  • Most errors are terminal: access_denied, expired_token, and anything unlisted all mean the client MUST stop polling.
  • The user code is short so humans can type it, and §6.1's base-20 alphabet drops vowels and digits so a misread letter fails as "wrong code" instead of silently matching another device; rate limits and short lifetimes - not longer codes - are what keep guessing hopeless.
  • The code-confirmation step (does your phone's code match the device's screen?) is the one tripwire that beats remote phishing.
The attack

Remote phishing, straight from RFC 8628 section 5.4

The flow's signature attack starts on the attacker's device. They begin a perfectly legitimate device authorization, then social-engineer the victim: "your stream stick was paused - visit this URL and enter this code." The victim, signing in with their own credentials on their own phone, approves what looks like their own device.

The approval lands on the attacker's poll. The wire shows the moment it happens: a token for the victim's account, delivered to a device the victim has never seen. Their own TV is still polling politely - it will poll until expiry and receive nothing butexpired_token.

The spec's mitigations are all on display in the console: consent screens that say what is being authorized and show device info, short code lifetimes, and - the one that actually catches it - the section 3.3.1 confirmation step when the code arrives embedded in a link or QR instead of typed from the device's screen.

References