3.3. User Interaction (用户交互)
🇬🇧 English
After receiving a successful authorization response, the client displays or otherwise communicates the "user_code" and the "verification_uri" to the end user and instructs them to visit the URI in a user agent on a secondary device (for example, in a browser on their mobile phone) and enter the user code.
+-----------------------------------------------+
| |
| Using a browser on another device, visit: |
| https://example.com/device |
| |
| And enter the code: |
| WDJB-MJHT |
| |
+-----------------------------------------------+
Figure 2: Example User Instruction
The authorizing user navigates to the "verification_uri" and authenticates with the authorization server in a secure TLS-protected [RFC8446] session. The authorization server prompts the end user to identify the device authorization session by entering the "user_code" provided by the client. The authorization server should then inform the user about the action they are undertaking and ask them to approve or deny the request. Once the user interaction is complete, the server instructs the user to return to their device.
During the user interaction, the device continuously polls the token endpoint with the "device_code", as detailed in Section 3.4, until the user completes the interaction, the code expires, or another error occurs. The "device_code" is not intended for the end user directly; thus, it should not be displayed during the interaction to avoid confusing the end user.
Authorization servers supporting this specification MUST implement a user-interaction sequence that starts with the user navigating to "verification_uri" and continues with them supplying the "user_code" at some stage during the interaction. Other than that, the exact sequence and implementation of the user interaction is up to the authorization server; for example, the authorization server may enable new users to sign up for an account during the authorization flow or add additional security verification steps.
It is NOT RECOMMENDED for authorization servers to include the user code ("user_code") in the verification URI ("verification_uri"), as this increases the length and complexity of the URI that the user must type. While the user must still type a similar number of characters with the "user_code" separated, once they successfully navigate to the "verification_uri", any errors in entering the code can be highlighted by the authorization server to improve the user experience. The next section documents the user interaction with "verification_uri_complete", which is designed to carry both pieces of information.
🇨🇳 中文
在收到成功的授权响应后,客户端向最终用户显示或以其他方式传达 "user_code" 和 "verification_uri",并指示他们在辅助设备(例如手机上的浏览器)上的用户代理中访问该 URI 并输入用户代码。
+-----------------------------------------------+
| |
| 使用另一台设备上的浏览器访问: |
| https://example.com/device |
| |
| 并输入代码: |
| WDJB-MJHT |
| |
+-----------------------------------------------+
图 2: 用户指令示例
授权用户导航到 "verification_uri" 并在安全的 TLS 保护 [RFC8446] 会话中与授权服务器进行身份验证。授权服务器提示最终用户通过输入客户端提供的 "user_code" 来识别设备授权会话。然后授权服务器应该告知用户他们正在进行的操作,并要求他们批准或拒绝该请求。一旦用户交互完成,服务器指示用户返回到其设备。
在用户交互期间,设备使用 "device_code" 持续轮询令牌端点,如第 3.4 节所述,直到用户完成交互、代码过期或发生另一个错误。"device_code" 不直接面向最终用户,因此在交互期间不应显示它,以避免混淆最终用户。
支持此规范的授权服务器必须 (MUST) 实现一个用户交互序列,该序列从用户导航到 "verification_uri" 开始,并在交互的某个阶段继续提供 "user_code"。除此之外,用户交互的确切序列和实现由授权服务器决定;例如,授权服务器可以允许新用户在授权流程期间注册帐户或添加额外的安全验证步骤。
不推荐 (NOT RECOMMENDED) 授权服务器在验证 URI ("verification_uri") 中包含用户代码 ("user_code"),因为这会增加用户必须键入的 URI 的长度和复杂性。虽然用户仍然必须输入类似数量的字符,但将 "user_code" 分开后,一旦他们成功导航到 "verification_uri",授权服务器就可以突出显示输入代码时的任何错误,以改善用户体验。下一节记录了使用 "verification_uri_complete" 的用户交互,它旨在携带这两条信息。
🇯🇵 日本語
成功した認可応答を受信した後、クライアントは "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" を使用したユーザーインタラクションについて説明します。
🇫🇷 Français
Après avoir reçu une réponse d'autorisation réussie, le client affiche ou communique autrement le "user_code" et le "verification_uri" à l'utilisateur final et lui demande de visiter l'URI dans un agent utilisateur sur un appareil secondaire (par exemple, dans un navigateur sur son téléphone mobile) et d'entrer le code utilisateur.
+-----------------------------------------------+
| |
| En utilisant un navigateur sur un autre |
| appareil, visitez: |
| https://example.com/device |
| |
| Et entrez le code: |
| WDJB-MJHT |
| |
+-----------------------------------------------+
Figure 2: Exemple d'instruction utilisateur
L'utilisateur autorisé navigue vers le "verification_uri" et s'authentifie auprès du serveur d'autorisation dans une session sécurisée protégée par TLS [RFC8446]. Le serveur d'autorisation invite l'utilisateur final à identifier la session d'autorisation de l'appareil en entrant le "user_code" fourni par le client. Le serveur d'autorisation doit ensuite informer l'utilisateur de l'action qu'il entreprend et lui demander d'approuver ou de refuser la demande. Une fois l'interaction utilisateur terminée, le serveur demande à l'utilisateur de retourner à son appareil.
Pendant l'interaction utilisateur, l'appareil interroge continuellement le point de terminaison de jeton avec le "device_code", comme détaillé dans la Section 3.4, jusqu'à ce que l'utilisateur termine l'interaction, que le code expire ou qu'une autre erreur se produise. Le "device_code" n'est pas destiné directement à l'utilisateur final; par conséquent, il ne doit pas être affiché pendant l'interaction pour éviter de confondre l'utilisateur final.
Les serveurs d'autorisation prenant en charge cette spécification DOIVENT implémenter une séquence d'interaction utilisateur qui commence par l'utilisateur naviguant vers "verification_uri" et se poursuit avec lui fournissant le "user_code" à un certain stade de l'interaction. En dehors de cela, la séquence exacte et la mise en œuvre de l'interaction utilisateur dépendent du serveur d'autorisation; par exemple, le serveur d'autorisation peut permettre aux nouveaux utilisateurs de s'inscrire à un compte pendant le flux d'autorisation ou d'ajouter des étapes de vérification de sécurité supplémentaires.
Il n'est PAS RECOMMANDÉ pour les serveurs d'autorisation d'inclure le code utilisateur ("user_code") dans l'URI de vérification ("verification_uri"), car cela augmente la longueur et la complexité de l'URI que l'utilisateur doit saisir. Bien que l'utilisateur doive toujours saisir un nombre similaire de caractères avec le "user_code" séparé, une fois qu'il a réussi à naviguer vers le "verification_uri", toute erreur dans la saisie du code peut être mise en évidence par le serveur d'autorisation pour améliorer l'expérience utilisateur. La section suivante documente l'interaction utilisateur avec "verification_uri_complete", qui est conçu pour transporter les deux informations.
🇩🇪 Deutsch
Nach Erhalt einer erfolgreichen Autorisierungsantwort zeigt der Client dem Endbenutzer den "user_code" und den "verification_uri" an oder kommuniziert sie auf andere Weise und weist ihn an, den URI in einem Benutzeragenten auf einem sekundären Gerät (z.B. in einem Browser auf seinem Mobiltelefon) zu besuchen und den Benutzercode einzugeben.
+-----------------------------------------------+
| |
| Verwenden Sie einen Browser auf einem |
| anderen Gerät, besuchen Sie: |
| https://example.com/device |
| |
| Und geben Sie den Code ein: |
| WDJB-MJHT |
| |
+-----------------------------------------------+
Abbildung 2: Beispiel für Benutzeranweisungen
Der autorisierende Benutzer navigiert zum "verification_uri" und authentifiziert sich beim Autorisierungsserver in einer sicheren TLS-geschützten [RFC8446] Sitzung. Der Autorisierungsserver fordert den Endbenutzer auf, die Geräteautorisierungssitzung zu identifizieren, indem er den vom Client bereitgestellten "user_code" eingibt. Der Autorisierungsserver sollte den Benutzer dann über die Aktion informieren, die er unternimmt, und ihn auffordern, die Anfrage zu genehmigen oder abzulehnen. Sobald die Benutzerinteraktion abgeschlossen ist, weist der Server den Benutzer an, zu seinem Gerät zurückzukehren.
Während der Benutzerinteraktion fragt das Gerät kontinuierlich den Token-Endpunkt mit dem "device_code" ab, wie in Abschnitt 3.4 beschrieben, bis der Benutzer die Interaktion abschließt, der Code abläuft oder ein anderer Fehler auftritt. Der "device_code" ist nicht direkt für den Endbenutzer bestimmt; daher sollte er während der Interaktion nicht angezeigt werden, um den Endbenutzer nicht zu verwirren.
Autorisierungsserver, die diese Spezifikation unterstützen, MÜSSEN eine Benutzerinteraktionssequenz implementieren, die damit beginnt, dass der Benutzer zum "verification_uri" navigiert und in einer Phase der Interaktion den "user_code" bereitstellt. Abgesehen davon liegt die genaue Abfolge und Implementierung der Benutzerinteraktion beim Autorisierungsserver; zum Beispiel kann der Autorisierungsserver neuen Benutzern ermöglichen, sich während des Autorisierungsablaufs für ein Konto anzumelden, oder zusätzliche Sicherheitsüberprüfungsschritte hinzufügen.
Es wird NICHT EMPFOHLEN, dass Autorisierungsserver den Benutzercode ("user_code") im Verifizierungs-URI ("verification_uri") einschließen, da dies die Länge und Komplexität des URI erhöht, den der Benutzer eingeben muss. Während der Benutzer mit dem getrennten "user_code" immer noch eine ähnliche Anzahl von Zeichen eingeben muss, können Fehler bei der Eingabe des Codes vom Autorisierungsserver hervorgehoben werden, um die Benutzererfahrung zu verbessern, sobald er erfolgreich zum "verification_uri" navigiert hat. Der nächste Abschnitt dokumentiert die Benutzerinteraktion mit "verification_uri_complete", das beide Informationen übertragen soll.
🇮🇹 Italiano
Dopo aver ricevuto una risposta di autorizzazione riuscita, il client visualizza o comunica in altro modo il "user_code" e il "verification_uri" all'utente finale e gli indica di visitare l'URI in un agente utente su un dispositivo secondario (ad esempio, in un browser sul loro telefono cellulare) e inserire il codice utente.
+-----------------------------------------------+
| |
| Utilizzando un browser su un altro |
| dispositivo, visita: |
| https://example.com/device |
| |
| E inserisci il codice: |
| WDJB-MJHT |
| |
+-----------------------------------------------+
Figura 2: Esempio di istruzione utente
L'utente autorizzante naviga al "verification_uri" e si autentica con il server di autorizzazione in una sessione sicura protetta da TLS [RFC8446]. Il server di autorizzazione richiede all'utente finale di identificare la sessione di autorizzazione del dispositivo inserendo il "user_code" fornito dal client. Il server di autorizzazione dovrebbe quindi informare l'utente dell'azione che sta intraprendendo e chiedergli di approvare o negare la richiesta. Una volta completata l'interazione dell'utente, il server indica all'utente di tornare al proprio dispositivo.
Durante l'interazione dell'utente, il dispositivo interroga continuamente l'endpoint token con il "device_code", come descritto nella Sezione 3.4, fino a quando l'utente completa l'interazione, il codice scade o si verifica un altro errore. Il "device_code" non è destinato direttamente all'utente finale; quindi, non dovrebbe essere visualizzato durante l'interazione per evitare di confondere l'utente finale.
I server di autorizzazione che supportano questa specifica DEVONO implementare una sequenza di interazione utente che inizia con l'utente che naviga al "verification_uri" e continua con lui che fornisce il "user_code" in una fase durante l'interazione. A parte questo, la sequenza esatta e l'implementazione dell'interazione utente dipendono dal server di autorizzazione; ad esempio, il server di autorizzazione può consentire ai nuovi utenti di registrarsi per un account durante il flusso di autorizzazione o aggiungere passaggi di verifica della sicurezza aggiuntivi.
NON È RACCOMANDATO per i server di autorizzazione includere il codice utente ("user_code") nell'URI di verifica ("verification_uri"), poiché ciò aumenta la lunghezza e la complessità dell'URI che l'utente deve digitare. Sebbene l'utente debba ancora digitare un numero simile di caratteri con il "user_code" separato, una volta che naviga con successo al "verification_uri", eventuali errori nell'inserimento del codice possono essere evidenziati dal server di autorizzazione per migliorare l'esperienza utente. La sezione successiva documenta l'interazione dell'utente con "verification_uri_complete", progettato per trasportare entrambe le informazioni.