3.5. Device Access Token Response (デバイスアクセストークンレスポンス)

ユーザーがグラントを承認した場合、トークンエンドポイントは [RFC6749] のセクション 5.1 で定義された成功応答で応答します。それ以外の場合は、[RFC6749] のセクション 5.2 で定義されたエラーで応答します。

[RFC6749] のセクション 5.2 で定義されたエラーコードに加えて、トークンエンドポイント応答でデバイス認可グラントで使用するために次のエラーコードが指定されています:

authorization_pending (認可保留中)

• エンドユーザーがまだユーザーインタラクションステップ(セクション 3.3)を完了していないため、認可リクエストはまだ保留中です。クライアントは、トークンエンドポイントへのアクセストークンリクエストを繰り返すべきです (SHOULD)(ポーリングとして知られるプロセス)。各新しいリクエストの前に、クライアントは、デバイス認可応答の "interval" パラメータで指定された秒数(セクション 3.2 参照)、または提供されていない場合は 5 秒以上待機しなければならず (MUST)、"slow_down" エラーによって要求されるポーリング間隔の増加を尊重する必要があります。

slow_down (速度低下)

• "authorization_pending" のバリアント。認可リクエストはまだ保留中であり、ポーリングを続行する必要がありますが、このリクエストおよびすべての後続のリクエストに対して間隔を 5 秒増やさなければなりません (MUST)。

access_denied (アクセス拒否)

• 認可リクエストが拒否されました。

expired_token (トークン期限切れ)

• "device_code" が期限切れになり、デバイス認可セッションが終了しました。クライアントは新しいデバイス認可リクエストを開始してもかまいません (MAY) が、不要なポーリングを避けるために再開する前にユーザーインタラクションを待つべきです (SHOULD)。

"authorization_pending" および "slow_down" エラーコードは特に独自の動作を定義します。これらは、OAuth クライアントがトークンリクエストを繰り返すことによってトークンエンドポイントをポーリングし続けるべきであることを示しているためです(上記で定義された正確な動作を実装)。クライアントが他のエラーコードを含むエラー応答を受信した場合、ポーリングを停止しなければならず (MUST)、たとえばユーザーにエラーを表示するなど、それに応じて反応すべきです (SHOULD)。

接続タイムアウトが発生した場合、クライアントは再試行する前に一方的にポーリング頻度を減らさなければなりません (MUST)。これを達成するために、各接続タイムアウトでポーリング間隔を 2 倍にするなどの指数バックオフアルゴリズムの使用が推奨されます (RECOMMENDED)。

この仕様の前提は、ユーザーがリクエストを認可する別のデバイスには、OAuth クライアントを持つデバイスに通信する方法がないということです。このプロトコルは、アウトバウンドリクエストのみが可能なテレビで実行されるアプリケーションなど、制限された環境でのプロトコルの実行可能性を最大化するために、一方向チャネルのみを必要とします。選択されたユーザーインタラクションインターフェイスに戻りチャネルが存在する場合、デバイスは、トークンリクエストを開始する前に、そのチャネルでユーザーがアクションを完了したことが通知されるまで待機してもかまいません (MAY)(ポーリングの代替として)。ただし、このような動作はこの仕様の範囲外です。