A sign-in flow for devices that are awkward to type on

Diagram of pending, slower-polling, and expired device-code states beside a user checking the account and permissions

A smart TV or kiosk may have no convenient keyboard for entering a password. OAuth 2.0 Device Authorization Grant offers another pattern: the device asks an authorization server for a device_code, a human-readable user_code, a verification address, an expiry, and a polling interval. The person opens the address on a separate phone or computer, enters the code, and reviews the account authorization. Meanwhile, the device checks the token endpoint at intervals until authorization finishes. RFC 8628, Sections 3.1–3.5

This solves an input problem; it does not prove who owns the device or who is standing nearby. A code is temporary information that correlates an authorization request with a later browser action. The design therefore needs clear consent, an expiry, and correct polling behavior. A person who can persuade a user to approve the wrong request may exploit the convenience of the flow.

Treat polling responses as protocol states

The initial response can include interval, a minimum number of seconds between token requests. Follow that value; if it is omitted, follow the default specified by RFC 8628. While the person has not approved the request, the server can return authorization_pending. That means keep waiting, not poll immediately in a tight loop. If it returns slow_down, increase the polling interval by five seconds and keep using the increased interval for later requests. This explicit rule keeps clients from inventing aggressive retry schedules that burden the authorization service.

The device and user codes have finite lifetimes. A client should stop treating them as usable after success, expiry, or another terminal result. A network timeout is different from authorization_pending: the client did not receive a protocol response and cannot infer which state the server reached. Handle it as a communication failure under a bounded retry policy. By contrast, slow_down is an explicit instruction and should change the schedule immediately. Keep these states distinct in the implementation and in logs so an operator can diagnose a stalled sign-in without exposing the codes themselves.

Make the approval understandable to the person

Show the verification address and its official domain on the device, and explain that the user will review an account and requested access on the separate screen. The browser should identify enough context for the person to recognize the device or the action they intended. A caller or message sender asking for a code may be trying to get the user to authorize an attacker-controlled device. Users should not relay a code to someone else. They should reach the verification page through the displayed official address or a trusted link, rather than an advertisement or an unrelated search result.

Because a visible code can be observed, services need short validity periods, unpredictable codes, and limits on guessing attempts. The authorization server should rate-limit user-code submissions and avoid responses that make it easy to discover whether another person's code is active. RFC 8628 has dedicated security considerations for guessing and remote phishing. Those sections identify protocol risks; they do not remove the need for a service to assess its own users, screens, support channels, and abuse patterns.

Expert implementation guidance and its limits

Microsoft identity platform documentation is useful practitioner documentation for seeing how a deployed provider exposes the flow. It describes the user code, verification URI, expiry, and polling interval returned by the device-code request, along with handling for authorization_pending and slow_down. It also advises starting the request when the user is ready to sign in. These are implementation details and guidance for Microsoft's platform, not promises that every OAuth provider uses identical lifetimes or response behavior. The RFC is the normative interoperability specification; the provider guide explains one product's API. An application should follow the standard state transitions while checking the current fields, limits, and error behavior of its chosen provider.

A robust client keeps the device code in protected memory, does not print it in telemetry, and stops polling on terminal errors. It gives the user a way to cancel and shows an expiry message that restarts the flow instead of silently reusing stale values. These are practical safeguards around the protocol. Whether the device can securely protect tokens, how consent is recorded, and how suspicious approvals are reviewed remain deployment decisions.

Sources