2026-09-26 · 6 min read · Rahul Chitturi
- oauth
- device-flow
- security
The OAuth device authorization grant lets an input-constrained device obtain authorization while a user completes interaction on a second device. The client receives a device code for token polling and a shorter user code for the verification experience.
Clients fail when they poll too quickly, treat authorization_pending as terminal, ignore slow_down, continue after expiry, or expose the device code in logs and support screenshots.
Separate the two device interactions
Record the trusted issuer, device authorization endpoint, token endpoint, client identity, requested scope, returned interval and expiry, verification URI, and local state. Redact device codes, access tokens, refresh tokens, and user-linked data.
- Show only trusted verification destinations.
- Keep the device code out of the user interface.
- Treat the user code as short-lived and sensitive.
- Bind the polling worker to one authorization attempt.
Implement the polling state machine
Wait at least the returned interval before the first and subsequent requests. Continue on authorization_pending, increase the interval as required after slow_down, stop on access_denied or expiry, and apply bounded network backoff without resetting the protocol timer.
A user cancelling locally should stop polling and clear transient state. Never launch overlapping poll requests or reuse a device code after a terminal response.
Exercise time and error boundaries
Use Flashman's URL tool for harmless endpoint fixtures, JSON formatter for sanitized responses, JWT decoder for synthetic token structure, and timestamp converter for polling and expiry timelines.
Test pending approval, slow_down, denial, expiry, malformed responses, clock changes, network loss, process restart, cancellation, duplicate workers, scope changes, issuer mix-ups, token rotation, and secret-safe observability.