RFC 8628 / START HERE
OAuth device authorization, before the details
OAuth 2.0 names an authorization framework. Its device authorization grant lets an app on a TV, printer or other input-constrained device request access without asking you to type your password into that device.
The device gives you a short user code and a verification address. You use a separate browser to sign in and approve or deny the request. Meanwhile, the device checks the authorization server using a different, machine-facing device code.
The idea in one picture
Limited-input device
Separate user browser
Authorization server
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
A remote control is awkward for login, and some devices cannot receive browser callbacks. A one-way instruction channel plus carefully paced outbound requests solves that problem. This flow is not a replacement for normal browser-based OAuth on capable phones.
A familiar example
Imagine a kiosk gives you a claim slip and asks you to confirm it at a staffed desk. The short slip identifies the request; it does not prove that the kiosk belongs to you. Check which device and action you are approving, especially if someone sent you a code.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- Request two codes for different channelsA limited-input device asks the authorization server for a short-lived session. The human code and the device code serve different jobs.→
- Approve on a separate browserThe user follows instructions on a second device. A convenience link can remove typing, but it does not remove confirmation or consent.→
- Wait correctly between token requestsPolling is deliberately paced. Pending responses, slow-down responses and transport timeouts have different effects on the next request.→
- Finish with a token or a terminal errorA server decision and a validated device request determine the result. Error names control whether the client can continue.→
- Recognize code theft and remote phishingShort human codes and machine codes face different attacks. A legitimate HTTPS login page does not prove that the initiating device is yours.→
- Discover endpoints and interpret the resultDiscovery, token fields and readable codes serve different purposes. Keep their meanings separate when building a device experience.→
This introduction explains RFC 8628 (2019). Read the original RFC ↗