3.3. User Interaction (ユーザーインタラクション)

成功した認可応答を受信した後、クライアントは "user_code" と "verification_uri" をエンドユーザーに表示または他の方法で伝達し、セカンダリデバイス(たとえば、携帯電話のブラウザ)のユーザーエージェントでその URI にアクセスし、ユーザーコードを入力するよう指示します。

+-----------------------------------------------+
|                                               |
|  別のデバイスでブラウザを使用して訪問:          |
|  https://example.com/device                   |
|                                               |
|  コードを入力:                                 |
|  WDJB-MJHT                                    |
|                                               |
+-----------------------------------------------+

            図 2: ユーザー指示の例

認可するユーザーは "verification_uri" に移動し、安全な TLS 保護された [RFC8446] セッションで認可サーバーと認証します。認可サーバーは、クライアントによって提供された "user_code" を入力することによってデバイス認可セッションを識別するようエンドユーザーに促します。次に、認可サーバーはユーザーが実行している操作についてユーザーに通知し、リクエストを承認または拒否するよう求める必要があります。ユーザーインタラクションが完了すると、サーバーはユーザーにデバイスに戻るよう指示します。

ユーザーインタラクション中、デバイスは、セクション 3.4 で詳述されているように、ユーザーがインタラクションを完了するまで、コードが期限切れになるまで、または別のエラーが発生するまで、"device_code" でトークンエンドポイントを継続的にポーリングします。"device_code" はエンドユーザーに直接意図されていないため、エンドユーザーを混乱させないように、インタラクション中に表示すべきではありません。

この仕様をサポートする認可サーバーは、ユーザーが "verification_uri" に移動することから始まり、インタラクションのある段階で "user_code" を提供し続けるユーザーインタラクションシーケンスを実装しなければなりません (MUST)。それ以外では、ユーザーインタラクションの正確なシーケンスと実装は認可サーバー次第です。たとえば、認可サーバーは、認可フロー中に新しいユーザーがアカウントにサインアップできるようにするか、追加のセキュリティ検証ステップを追加する場合があります。

認可サーバーが検証 URI ("verification_uri") にユーザーコード ("user_code") を含めることは推奨されません (NOT RECOMMENDED)。これにより、ユーザーが入力しなければならない URI の長さと複雑さが増加するためです。"user_code" を分離した状態でユーザーが同様の数の文字を入力する必要がある一方で、"verification_uri" に正常に移動すると、認可サーバーはコードの入力エラーを強調表示してユーザーエクスペリエンスを向上させることができます。次のセクションでは、両方の情報を伝達するように設計された "verification_uri_complete" を使用したユーザーインタラクションについて説明します。