การมอบสิทธิ์อุปกรณ์

Some clients have no browser or only a limited keypad: smart TVs, media consoles, printers, and CLI tools. The classic Authorization Code Flow assumes a rich browser for the user-agent redirect, which these devices cannot provide.

The Device Authorization Grant (RFC 8628) solves this by letting the user complete authorization on a second device (phone or laptop) while the constrained device polls for the result.

The flow introduces a new device authorization endpoint alongside the standard token endpoint.

• /device_authorization — the device requests codes here.
• /token — the device polls here with grant type urn:ietf:params:oauth:grant-type:device_code.

No redirect URI is involved at all.

The device makes a POST to the device authorization endpoint with its client_id and desired scope.

The server returns a device_code (used by the machine), a user_code (typed by the human), a verification_uri, an expires_in, and an interval for polling.

The device displays a short message: Go to example.com/device and enter code WDJB-MJHT.

A verification_uri_complete may also be returned, embedding the code so a QR code can carry the whole link.

On their phone or laptop, the user opens the verification URI, logs in, enters the user_code, and approves the requested scopes. This happens in a full browser, so MFA and rich consent screens all work normally.

Meanwhile the device polls the token endpoint at the given interval, sending the device_code.

Until the user finishes, the server returns errors that tell the device how to behave:

• authorization_pending — keep polling, user has not approved yet.
• slow_down — increase the interval by 5 seconds.
• access_denied — user rejected; stop.
• expired_token — codes expired; restart.

Once the user approves, the next poll returns a normal token response with an access_token (and optionally a refresh_token), exactly like other grants.

A pseudo-implementation of the polling logic, respecting slow_down:

Keep user_codes short but high-entropy to resist brute force, and rate-limit the verification page. Because there is no redirect, phishing risk shifts to the verification URI — always show the user exactly which app and scopes they are approving.

Test your understanding of the device grant.

The Device Authorization Grant lets browserless devices authenticate users via a second device.

• Device gets a device_code + user_code from the device endpoint.
• User approves on a phone/laptop at the verification URI.
• Device polls the token endpoint, handling authorization_pending and slow_down.
• On approval it receives normal access and refresh tokens.