メインコンテンツまでスキップ

3.1. Device Authorization Request (デバイス認可リクエスト)

この仕様は、新しい OAuth エンドポイントであるデバイス認可エンドポイント (device authorization endpoint) を定義します。これは、ユーザーがユーザーエージェント(すなわちブラウザ)を介して対話する [RFC6749] で定義された OAuth 認可エンドポイントとは別のものです。比較すると、デバイス認可エンドポイントを使用する場合、デバイス上の OAuth クライアントは、ユーザーエージェントでリクエストを提示することなく認可サーバーと直接対話し、エンドユーザーは別のデバイスでリクエストを認可します。この対話は次のように定義されます。

クライアントは、デバイス認可エンドポイントへの HTTP "POST" リクエストを作成して認可サーバーから検証コードのセットを要求することにより、認可フローを開始します。

クライアントは、[RFC6749] の付録 B に従って "application/x-www-form-urlencoded" 形式を使用し、HTTP リクエストエンティティボディに UTF-8 文字エンコーディングで次のパラメータを含めることにより、デバイス認可エンドポイントにデバイス認可リクエストを行います:

client_id (クライアント識別子)

  • [RFC6749] のセクション 3.2.1 で説明されているように、クライアントが認可サーバーで認証していない場合は必須 (REQUIRED)。
  • [RFC6749] のセクション 2.2 で説明されているクライアント識別子。

scope (スコープ)

  • 任意 (OPTIONAL)。[RFC6749] のセクション 3.3 で定義されたアクセスリクエストのスコープ。

例えば、クライアントは次の HTTPS リクエストを行います:

POST /device_authorization HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

client_id=1406020730&scope=example_scope

デバイスからのすべてのリクエストは、トランスポート層セキュリティ (TLS) プロトコル [RFC8446] を使用し、BCP 195 [RFC7525] のベストプラクティスを実装しなければなりません (MUST)。

値なしで送信されたパラメータは、リクエストから省略されたかのように扱わなければなりません (MUST)。認可サーバーは、認識できないリクエストパラメータを無視しなければなりません (MUST)。リクエストおよびレスポンスパラメータは複数回含めてはなりません (MUST NOT)。

[RFC6749] のセクション 3.2.1 のクライアント認証要件がこのエンドポイントへのリクエストに適用されます。これは、機密クライアント(クライアント資格情報を確立したもの)がトークンエンドポイントへのリクエストを行うときと同じ方法で認証し、公開クライアントが自身を識別するために "client_id" パラメータを提供することを意味します。

このプロトコルのポーリングの性質(セクション 3.4 で指定)により、トークンエンドポイントの容量を過負荷にしないように注意が必要です。トークンエンドポイントへの不要なリクエストを避けるために、クライアントは、アプリが起動したときや以前の認可セッションが期限切れまたは失敗したときなど、自動的にではなく、ユーザーによって促されたときにのみデバイス認可リクエストを開始すべきです (SHOULD)。

に最終更新