OAuth2 & OpenID Connect Deep Dive · درس

منحة تفويض الجهاز

تعلّموا منحة تفويض الجهاز في OAuth2 ‏(RFC 8628)، المستخدمة من الأجهزة محدودة الإدخال مثل أجهزة التلفاز الذكية ووحدات الألعاب وأدوات CLI للحصول على الرموز عبر جهاز ثانوي.

منحة تفويض الجهاز درس مجاني في OAuth2 & OpenID Connect Deep Dive على CoddyKit. هذا هو الدرس 4 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في 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 type urn: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 email

Step 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-123

Polling 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_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.

الأسئلة الشائعة

هل درس «منحة تفويض الجهاز» مجاني؟

نعم — نص درس «منحة تفويض الجهاز» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة OAuth2 & OpenID Connect Deep Dive، انتقل إلى CoddyKit PRO. تتضمن دورة OAuth2 & OpenID Connect Deep Dive 4 دروس في المجموع.

ماذا ستتعلم في «منحة تفويض الجهاز»؟

تعلّموا منحة تفويض الجهاز في OAuth2 ‏(RFC 8628)، المستخدمة من الأجهزة محدودة الإدخال مثل أجهزة التلفاز الذكية ووحدات الألعاب وأدوات CLI للحصول على الرموز عبر جهاز ثانوي. تتمرن على OAuth2 & OpenID Connect Deep Dive مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.

هل أحتاج إلى خبرة سابقة لأبدأ OAuth2 & OpenID Connect Deep Dive؟

لا تُشترط خبرة سابقة. OAuth2 & OpenID Connect Deep Dive على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 4 من أصل 4.

كم من الوقت يستغرق درس «منحة تفويض الجهاز»؟

معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.

هل يمكنني كتابة وتشغيل أكواد في درس OAuth2 & OpenID Connect Deep Dive هذا؟

نعم. كل درس في OAuth2 & OpenID Connect Deep Dive يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.

جميع الدروس في هذه الدورة

← العودة إلى OAuth2 & OpenID Connect Deep Dive