デバイス認可グラント
スマートテレビ、ゲーム機、CLIツールなど入力が制限されたデバイスが、別のデバイスを介してトークンを取得するOAuth2 Device Authorization Grant（RFC 8628）を学びます。
「デバイス認可グラント」はCoddyKit上の無料OAuth2 & OpenID Connect Deep Diveレッスンです。 これはレッスン4/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはOAuth2 & OpenID Connect Deep Dive学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 OAuth2 & OpenID Connect Deep Diveコースには全4レッスンが含まれています。
このレッスンの一部はまだ翻訳されておらず、英語で表示されています。
Why a Device Grant?
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 Two Endpoints
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 typeurn:ietf:params:oauth:grant-type:device_code.
No redirect URI is involved at all.
Step 1: Requesting Device Codes
The device makes a POST to the device authorization endpoint with its client_id and desired scope.
POST /device_authorization HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded
client_id=tv-app-123&scope=profile emailStep 2: The Response
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.
{
"device_code": "GmRhmhcxhwAzkoEqiMEg",
"user_code": "WDJB-MJHT",
"verification_uri": "https://example.com/device",
"expires_in": 900,
"interval": 5
}Step 3: User Instructions
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.
Step 4: User Authorizes
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.
Step 5: Device Polls the Token Endpoint
Meanwhile the device polls the token endpoint at the given interval, sending the device_code.
POST /token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:device_code
&device_code=GmRhmhcxhwAzkoEqiMEg
&client_id=tv-app-123Polling Responses
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.
Step 6: Success
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.
{
"access_token": "eyJhbGciOi...",
"token_type": "Bearer",
"expires_in": 3600,
"refresh_token": "8xLOxBtZp8"
}A Simple Poll Loop
A pseudo-implementation of the polling logic, respecting slow_down:
let interval = 5;
while (true) {
await sleep(interval * 1000);
const res = await pollToken(deviceCode);
if (res.access_token) return res;
if (res.error === 'slow_down') interval += 5;
else if (res.error === 'authorization_pending') continue;
else throw new Error(res.error);
}Security Considerations
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.
Quick Check
Test your understanding of the device grant.
Recap
The Device Authorization Grant lets browserless devices authenticate users via a second device.
- Device gets a
device_code+user_codefrom the device endpoint. - User approves on a phone/laptop at the verification URI.
- Device polls the token endpoint, handling
authorization_pendingandslow_down. - On approval it receives normal access and refresh tokens.
よくある質問
「デバイス認可グラント」レッスンは無料ですか？
はい。「デバイス認可グラント」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、OAuth2 & OpenID Connect Deep Diveコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 OAuth2 & OpenID Connect Deep Diveコースには全4レッスンが含まれています。
「デバイス認可グラント」で何を学びますか？
スマートテレビ、ゲーム機、CLIツールなど入力が制限されたデバイスが、別のデバイスを介してトークンを取得するOAuth2 Device Authorization Grant（RFC 8628）を学びます。 ブラウザで直接実行するハンズオンコードでOAuth2 & OpenID Connect Deep Diveを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。
OAuth2 & OpenID Connect Deep Diveを始めるのに経験は必要ですか？
事前経験は必要ありません。CoddyKitのOAuth2 & OpenID Connect Deep Diveは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン4/4です。
「デバイス認可グラント」レッスンにはどのくらい時間がかかりますか？
ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。
このOAuth2 & OpenID Connect Deep Diveレッスンでコードを書いて実行できますか？
はい。すべてのOAuth2 & OpenID Connect Deep Diveレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。