OAuth 2.0 Device Authorization Flow Animation

Step through OAuth device authorization, polling, and token issuance for input-constrained IoT devices

animation
security
oauth
device-flow
authorization
iot-security
interactive
A standalone OAuth 2.0 Device Authorization Flow lab with IoT scenarios, protocol stages, polling and terminal response modes, phishing risk inspection, token handling notes, technical accuracy checks, common misreads, and practice prompts.
Security OAuth 2.0 Device Flow RFC 8628

OAuth Device Flow Lab

Follow how an input-constrained IoT device gets authorization without asking the user to type a password on the device. The animation separates the displayed user_code, the opaque device_code, the polling interval, and the terminal token response.

Requesting code Device state
Not polling Token endpoint response
No user action User verification
No token Credential status

Device Flow Controls

Use the stages, scenarios, risk modes, and lenses together. A learner should be able to predict the next protocol response before stepping forward.

Device code request

The input-constrained device starts by requesting a device authorization package from the authorization server.

Flow lens
OAuth 2.0 device authorization flow diagram Diagram of an IoT device, authorization server, user browser, optional attacker page, polling loop, token issuance, and resource API access. POST /device_authorization device_code, user_code, interval user enters code at trusted URI POST /token poll loop access_token or terminal error Bearer token API call wrong verification page Smart TV remote input only Authorization Server issues codes User browser phone or laptop Resource API waiting for bearer token Risk page Untrusted code entry site No token should be issued Teach URI verification Displayed on device WDJB-MJHT at auth.example/device Polling interval timeline interval: 5 seconds, expires: 1800 seconds token API

Independent Learning Support

These cards are written for learners who know basic web authentication but may not have seen the device authorization grant before.

What moves

  • The device code request and response move between the IoT device and authorization server.
  • The user code moves only through the human-visible channel: device display to trusted browser page.
  • The access token appears only after the token endpoint returns success.

What to check

  • Does the device respect the interval and slow_down response?
  • Is the user entering the code at the expected authorization server URI?
  • Are access and refresh tokens treated as bearer credentials that need protection?

Why IoT uses it

  • Smart TVs, gateways, and sensors often cannot safely collect passwords or MFA codes.
  • The flow lets the user authenticate on a device that has a full browser and security controls.
  • The IoT device receives scoped tokens, not the user's account password.
Technical Accuracy Notes
  • RFC 8628 names this the OAuth 2.0 Device Authorization Grant and defines device_code, user_code, verification_uri, optional verification_uri_complete, expires_in, and interval.
  • Polling responses include authorization_pending, slow_down, access_denied, and expired_token. A device should not create or assume a token before the token endpoint returns a successful token response.
  • The access token is a bearer credential in the OAuth model. Whoever can present it may be able to access the protected resource until it expires or is revoked.
  • The user code is meant for human entry. The opaque device code is sent by the device to the token endpoint and should not be exposed as a human login secret.
Common Misreads
  • Misread: The device logs in as the user. Correction: the user authorizes through the authorization server, then the device receives scoped tokens.
  • Misread: Faster polling is harmless. Correction: clients must follow the polling interval and handle slow_down.
  • Misread: Any page that accepts the code is fine. Correction: entering the code on a phishing page can authorize the wrong party.
Practice Prompts
  • Run the Smart TV scenario in valid mode. Which exact event causes the token to appear?
  • Switch to Over-polling mode. What should an embedded client change after receiving slow_down?
  • Switch to Code phishing mode. What should the user verify before entering a code?
  • Use Factory sensor mode. How would a device without a screen present the verification URI and user code safely?
Standards And Related Tools

Source standards: RFC 8628 Device Authorization Grant, RFC 6749 OAuth 2.0 Authorization Framework, and RFC 6750 Bearer Token Usage.

Related IoTclass tools: Device Provisioning Flow, Network Security Analyzer, Network Segmentation Defense, and STRIDE Threat Modeling.