1. Introduction (简介)
🇬🇧 English
This OAuth 2.0 [RFC6749] protocol extension enables OAuth clients to request user authorization from applications on devices that have limited input capabilities or lack a suitable browser. Such devices include smart TVs, media consoles, picture frames, and printers, which lack an easy input method or a suitable browser required for traditional OAuth interactions. The authorization flow defined by this specification, sometimes referred to as the "device flow", instructs the user to review the authorization request on a secondary device, such as a smartphone, which does have the requisite input and browser capabilities to complete the user interaction.
The device authorization grant is not intended to replace browser-based OAuth in native apps on capable devices like smartphones. Those apps should follow the practices specified in "OAuth 2.0 for Native Apps" [RFC8252].
The operating requirements for using this authorization grant type are:
(1) The device is already connected to the Internet.
(2) The device is able to make outbound HTTPS requests.
(3) The device is able to display or otherwise communicate a URI and code sequence to the user.
(4) The user has a secondary device (e.g., personal computer or smartphone) from which they can process the request.
As the device authorization grant does not require two-way communication between the OAuth client on the device and the user agent (unlike other OAuth 2 grant types, such as the authorization code and implicit grant types), it supports several use cases that cannot be served by those other approaches.
Instead of interacting directly with the end user's user agent (i.e., browser), the device client instructs the end user to use another computer or device and connect to the authorization server to approve the access request. Since the protocol supports clients that can't receive incoming requests, clients poll the authorization server repeatedly until the end user completes the approval process.
The device client typically chooses the set of authorization servers to support (i.e., its own authorization server or those of providers with which it has relationships). It is common for the device client to support only one authorization server, such as in the case of a TV application for a specific media provider that supports only that media provider's authorization server. The user may not yet have an established relationship with that authorization provider, though one can potentially be set up during the authorization flow.
+----------+ +----------------+
| |>---(A)-- Client Identifier --->| |
| | | |
| |<---(B)-- Device Code, ---<| |
| | User Code, | |
| Device | & Verification URI | |
| Client | | |
| | [polling] | |
| |>---(E)-- Device Code --->| |
| | & Client Identifier | |
| | | Authorization |
| |<---(F)-- Access Token ---<| Server |
+----------+ (& Optional Refresh Token) | |
v | |
: | |
(C) User Code & Verification URI | |
: | |
v | |
+----------+ | |
| End User | | |
| at |<---(D)-- End user reviews --->| |
| Browser | authorization request | |
+----------+ +----------------+
Figure 1: Device Authorization Flow
The device authorization flow illustrated in Figure 1 includes the following steps:
(A) The client requests access from the authorization server and includes its client identifier in the request.
(B) The authorization server issues a device code and an end-user code and provides the end-user verification URI.
(C) The client instructs the end user to use a user agent on another device and visit the provided end-user verification URI. The client provides the user with the end-user code to enter in order to review the authorization request.
(D) The authorization server authenticates the end user (via the user agent), and prompts the user to input the user code provided by the device client. The authorization server validates the user code provided by the user, and prompts the user to accept or decline the request.
(E) While the end user reviews the client's request (step D), the client repeatedly polls the authorization server to find out if the user completed the user authorization step. The client includes the device code and its client identifier.
(F) The authorization server validates the device code provided by the client and responds with the access token if the client is granted access, an error if they are denied access, or an indication that the client should continue to poll.
🇨🇳 中文
此 OAuth 2.0 [RFC6749] 协议扩展使 OAuth 客户端能够从输入能力受限或缺少合适浏览器的设备上的应用程序请求用户授权。此类设备包括智能电视、媒体控制台、相框和打印机,它们缺少传统 OAuth 交互所需的便捷输入方法或合适的浏览器。本规范定义的授权流程(有时称为"设备流")指示用户在辅助设备(如智能手机)上审查授权请求,该辅助设备具有完成用户交互所需的输入和浏览器能力。
设备授权许可并非旨在取代智能手机等有能力设备上原生应用中基于浏览器的 OAuth。这些应用应遵循"OAuth 2.0 for Native Apps" [RFC8252] 中指定的实践。
使用此授权许可类型的操作要求如下:
(1) 设备已连接到互联网。
(2) 设备能够发出出站 HTTPS 请求。
(3) 设备能够向用户显示或以其他方式传达 URI 和代码序列。
(4) 用户拥有可以处理请求的辅助设备(例如个人计算机或智能手机)。
由于设备授权许可不需要设备上的 OAuth 客户端与用户代理之间的双向通信(不同于其他 OAuth 2 许可类型,如授权码和隐式许可类型),因此它支持其他方法无法满足的多种用例。
设备客户端不直接与最终用户的用户代理(即浏览器)交互,而是指示最终用户使用另一台计算机或设备并连接到授权服务器以批准访问请求。由于该协议支持无法接收传入请求的客户端,因此客户端反复轮询授权服务器,直到最终用户完成批准过程。
设备客户端通常选择要支持的授权服务器集(即其自己的授权服务器或与其有关系的提供商的授权服务器)。设备客户端通常仅支持一个授权服务器,例如特定媒体提供商的电视应用程序仅支持该媒体提供商的授权服务器。用户可能尚未与该授权提供商建立关系,但可以在授权流程期间建立关系。
+----------+ +----------------+
| |>---(A)-- Client Identifier --->| |
| | | |
| |<---(B)-- Device Code, ---<| |
| | User Code, | |
| Device | & Verification URI | |
| Client | | |
| | [polling] | |
| |>---(E)-- Device Code --->| |
| | & Client Identifier | |
| | | Authorization |
| |<---(F)-- Access Token ---<| Server |
+----------+ (& Optional Refresh Token) | |
v | |
: | |
(C) User Code & Verification URI | |
: | |
v | |
+----------+ | |
| End User | | |
| at |<---(D)-- End user reviews --->| |
| Browser | authorization request | |
+----------+ +----------------+
图 1: 设备授权流程
图 1 所示的设备授权流程包括以下步骤:
(A) 客户端向授权服务器请求访问权限,并在请求中包含其客户端标识符。
(B) 授权服务器颁发设备代码和最终用户代码,并提供最终用户验证 URI。
(C) 客户端指示最终用户在另一设备上使用用户代理并访问提供的最终用户验证 URI。客户端向用户提供最终用户代码以便输入,从而审查授权请求。
(D) 授权服务器对最终用户进行身份验证(通过用户代理),并提示用户输入设备客户端提供的用户代码。授权服务器验证用户提供的用户代码,并提示用户接受或拒绝该请求。
(E) 当最终用户审查客户端的请求时(步骤 D),客户端反复轮询授权服务器以查明用户是否完成了用户授权步骤。客户端包括设备代码及其客户端标识符。
(F) 授权服务器验证客户端提供的设备代码,如果客户端被授予访问权限则响应访问令牌,如果被拒绝访问则响应错误,或者指示客户端应继续轮询。
🇯🇵 日本語
この OAuth 2.0 [RFC6749] プロトコル拡張により、OAuth クライアントは、入力機能が制限されているか、適切なブラウザがないデバイス上のアプリケーションからユーザー認可を要求できるようになります。このようなデバイスには、スマートTV、メディアコンソール、フォトフレーム、プリンターなど、従来の OAuth インタラクションに必要な簡単な入力方法や適切なブラウザがないものが含まれます。本仕様で定義された認可フロー(「デバイスフロー」と呼ばれることもあります)は、ユーザーインタラクションを完了するために必要な入力およびブラウザ機能を持つスマートフォンなどのセカンダリデバイスで認可リクエストを確認するようユーザーに指示します。
デバイス認可グラントは、スマートフォンのような能力のあるデバイス上のネイティブアプリでブラウザベースの OAuth を置き換えることを意図したものではありません。これらのアプリは、"OAuth 2.0 for Native Apps" [RFC8252] で指定されたプラクティスに従う必要があります。
この認可グラントタイプを使用するための動作要件は次のとおりです:
(1) デバイスがすでにインターネットに接続されている。
(2) デバイスがアウトバウンド HTTPS リクエストを行うことができる。
(3) デバイスが URI とコードシーケンスをユーザーに表示または他の方法で伝達できる。
(4) ユーザーがリクエストを処理できるセカンダリデバイス(例: パーソナルコンピュータまたはスマートフォン)を持っている。
デバイス認可グラントは、デバイス上の OAuth クライアントとユーザーエージェント間の双方向通信を必要としないため(認可コードや暗黙的グラントタイプなどの他の OAuth 2 グラントタイプとは異なります)、他のアプローチでは対応できない複数のユースケースをサポートします。
エンドユーザーのユーザーエージェント(すなわちブラウザ)と直接対話する代わりに、デバイスクライアントは、エンドユーザーに別のコンピュータまたはデバイスを使用し、認可サーバーに接続してアクセスリクエストを承認するよう指示します。プロトコルは受信リクエストを受け取れないクライアントをサポートしているため、クライアントはエンドユーザーが承認プロセスを完了するまで認可サーバーを繰り返しポーリングします。
デバイスクライアントは通常、サポートする認可サーバーのセット(つまり、独自の認可サーバーまたは関係を持つプロバイダーのサーバー)を選択します。特定のメディアプロバイダーのTV アプリケーションがそのメディアプロバイダーの認可サーバーのみをサポートする場合など、デバイスクライアントが1つの認可サーバーのみをサポートすることは一般的です。ユーザーはその認可プロバイダーとの確立された関係をまだ持っていない可能性がありますが、認可フロー中に関係を設定できる可能性があります。
+----------+ +----------------+
| |>---(A)-- Client Identifier --->| |
| | | |
| |<---(B)-- Device Code, ---<| |
| | User Code, | |
| Device | & Verification URI | |
| Client | | |
| | [polling] | |
| |>---(E)-- Device Code --->| |
| | & Client Identifier | |
| | | Authorization |
| |<---(F)-- Access Token ---<| Server |
+----------+ (& Optional Refresh Token) | |
v | |
: | |
(C) User Code & Verification URI | |
: | |
v | |
+----------+ | |
| End User | | |
| at |<---(D)-- End user reviews --->| |
| Browser | authorization request | |
+----------+ +----------------+
図 1: デバイス認可フロー
図 1 に示すデバイス認可フローには、次のステップが含まれます:
(A) クライアントは認可サーバーにアクセスを要求し、リクエストにクライアント識別子を含めます。
(B) 認可サーバーはデバイスコードとエンドユーザーコードを発行し、エンドユーザー検証 URI を提供します。
(C) クライアントは、エンドユーザーに別のデバイスでユーザーエージェントを使用し、提供されたエンドユーザー検証 URI にアクセスするよう指示します。クライアントは、認可リクエストを確認するために入力するエンドユーザーコードをユーザーに提供します。
(D) 認可サーバーは(ユーザーエージェントを介して)エンドユーザーを認証し、デバイスクライアントによって提供されたユーザーコードを入力するようユーザーに促します。認可サーバーはユーザーによって提供されたユーザーコードを検証し、リクエストを承認または拒否するようユーザーに促します。
(E) エンドユーザーがクライアントのリクエストを確認している間(ステップ D)、クライアントは、ユーザーがユーザー認可ステップを完了したかどうかを確認するために認可サーバーを繰り返しポーリングします。クライアントはデバイスコードとそのクライアント識別子を含めます。
(F) 認可サーバーは、クライアントによって提供されたデバイスコードを検証し、クライアントにアクセスが許可された場合はアクセストークンで応答し、アクセスが拒否された場合はエラーで応答するか、クライアントがポーリングを続行する必要があることを示します。
🇫🇷 Français
Cette extension de protocole OAuth 2.0 [RFC6749] permet aux clients OAuth de demander l'autorisation de l'utilisateur à partir d'applications sur des appareils ayant des capacités d'entrée limitées ou manquant d'un navigateur approprié. Ces appareils incluent les téléviseurs intelligents, les consoles multimédias, les cadres photo et les imprimantes, qui manquent d'une méthode d'entrée facile ou d'un navigateur approprié requis pour les interactions OAuth traditionnelles. Le flux d'autorisation défini par cette spécification, parfois appelé "flux d'appareil", demande à l'utilisateur d'examiner la demande d'autorisation sur un appareil secondaire, tel qu'un smartphone, qui dispose des capacités d'entrée et de navigateur nécessaires pour compléter l'interaction utilisateur.
L'autorisation d'appareil n'est pas destinée à remplacer OAuth basé sur le navigateur dans les applications natives sur des appareils capables comme les smartphones. Ces applications doivent suivre les pratiques spécifiées dans "OAuth 2.0 for Native Apps" [RFC8252].
Les exigences opérationnelles pour l'utilisation de ce type d'autorisation sont:
(1) L'appareil est déjà connecté à Internet.
(2) L'appareil est capable d'effectuer des requêtes HTTPS sortantes.
(3) L'appareil est capable d'afficher ou de communiquer autrement un URI et une séquence de code à l'utilisateur.
(4) L'utilisateur dispose d'un appareil secondaire (par exemple, un ordinateur personnel ou un smartphone) à partir duquel il peut traiter la demande.
Étant donné que l'autorisation d'appareil ne nécessite pas de communication bidirectionnelle entre le client OAuth sur l'appareil et l'agent utilisateur (contrairement à d'autres types d'autorisation OAuth 2, tels que les types d'autorisation de code d'autorisation et implicite), elle prend en charge plusieurs cas d'utilisation qui ne peuvent pas être servis par ces autres approches.
Au lieu d'interagir directement avec l'agent utilisateur de l'utilisateur final (c'est-à-dire le navigateur), le client de l'appareil demande à l'utilisateur final d'utiliser un autre ordinateur ou appareil et de se connecter au serveur d'autorisation pour approuver la demande d'accès. Étant donné que le protocole prend en charge les clients qui ne peuvent pas recevoir de demandes entrantes, les clients interrogent le serveur d'autorisation de manière répétée jusqu'à ce que l'utilisateur final termine le processus d'approbation.
Le client de l'appareil choisit généralement l'ensemble des serveurs d'autorisation à prendre en charge (c'est-à-dire son propre serveur d'autorisation ou ceux des fournisseurs avec lesquels il a des relations). Il est courant que le client de l'appareil ne prenne en charge qu'un seul serveur d'autorisation, comme dans le cas d'une application TV pour un fournisseur de médias spécifique qui ne prend en charge que le serveur d'autorisation de ce fournisseur de médias. L'utilisateur peut ne pas encore avoir de relation établie avec ce fournisseur d'autorisation, bien qu'une relation puisse potentiellement être établie pendant le flux d'autorisation.
+----------+ +----------------+
| |>---(A)-- Client Identifier --->| |
| | | |
| |<---(B)-- Device Code, ---<| |
| | User Code, | |
| Device | & Verification URI | |
| Client | | |
| | [polling] | |
| |>---(E)-- Device Code --->| |
| | & Client Identifier | |
| | | Authorization |
| |<---(F)-- Access Token ---<| Server |
+----------+ (& Optional Refresh Token) | |
v | |
: | |
(C) User Code & Verification URI | |
: | |
v | |
+----------+ | |
| End User | | |
| at |<---(D)-- End user reviews --->| |
| Browser | authorization request | |
+----------+ +----------------+
Figure 1: Flux d'autorisation d'appareil
Le flux d'autorisation d'appareil illustré à la Figure 1 comprend les étapes suivantes:
(A) Le client demande l'accès au serveur d'autorisation et inclut son identifiant client dans la demande.
(B) Le serveur d'autorisation émet un code d'appareil et un code d'utilisateur final et fournit l'URI de vérification de l'utilisateur final.
(C) Le client demande à l'utilisateur final d'utiliser un agent utilisateur sur un autre appareil et de visiter l'URI de vérification de l'utilisateur final fourni. Le client fournit à l'utilisateur le code d'utilisateur final à entrer afin d'examiner la demande d'autorisation.
(D) Le serveur d'autorisation authentifie l'utilisateur final (via l'agent utilisateur) et invite l'utilisateur à saisir le code utilisateur fourni par le client de l'appareil. Le serveur d'autorisation valide le code utilisateur fourni par l'utilisateur et invite l'utilisateur à accepter ou à refuser la demande.
(E) Pendant que l'utilisateur final examine la demande du client (étape D), le client interroge de manière répétée le serveur d'autorisation pour savoir si l'utilisateur a terminé l'étape d'autorisation de l'utilisateur. Le client inclut le code d'appareil et son identifiant client.
(F) Le serveur d'autorisation valide le code d'appareil fourni par le client et répond avec le jeton d'accès si le client se voit accorder l'accès, une erreur s'il se voit refuser l'accès, ou une indication que le client doit continuer à interroger.
🇩🇪 Deutsch
Diese OAuth 2.0 [RFC6749] Protokollerweiterung ermöglicht es OAuth-Clients, Benutzerautorisierung von Anwendungen auf Geräten anzufordern, die über begrenzte Eingabefähigkeiten verfügen oder keinen geeigneten Browser haben. Zu diesen Geräten gehören Smart-TVs, Medienkonsolen, Bilderrahmen und Drucker, denen eine einfache Eingabemethode oder ein geeigneter Browser fehlt, der für traditionelle OAuth-Interaktionen erforderlich ist. Der durch diese Spezifikation definierte Autorisierungsablauf, manchmal als "Geräteablauf" bezeichnet, weist den Benutzer an, die Autorisierungsanfrage auf einem sekundären Gerät, wie einem Smartphone, zu überprüfen, das über die erforderlichen Eingabe- und Browserfähigkeiten verfügt, um die Benutzerinteraktion abzuschließen.
Die Geräteautorisierungsgenehmigung ist nicht dazu gedacht, browserbasiertes OAuth in nativen Apps auf fähigen Geräten wie Smartphones zu ersetzen. Diese Apps sollten den in "OAuth 2.0 for Native Apps" [RFC8252] spezifizierten Praktiken folgen.
Die Betriebsanforderungen für die Verwendung dieses Autorisierungsgenehmigungstyps sind:
(1) Das Gerät ist bereits mit dem Internet verbunden.
(2) Das Gerät ist in der Lage, ausgehende HTTPS-Anfragen zu stellen.
(3) Das Gerät ist in der Lage, dem Benutzer einen URI und eine Codesequenz anzuzeigen oder anderweitig zu kommunizieren.
(4) Der Benutzer verfügt über ein sekundäres Gerät (z.B. einen Personal Computer oder ein Smartphone), von dem aus er die Anfrage verarbeiten kann.
Da die Geräteautorisierungsgenehmigung keine bidirektionale Kommunikation zwischen dem OAuth-Client auf dem Gerät und dem Benutzeragenten erfordert (im Gegensatz zu anderen OAuth 2-Genehmigungstypen wie den Autorisierungscode- und impliziten Genehmigungstypen), unterstützt sie mehrere Anwendungsfälle, die von diesen anderen Ansätzen nicht bedient werden können.
Anstatt direkt mit dem Benutzeragenten des Endbenutzers (d.h. Browser) zu interagieren, weist der Geräteclient den Endbenutzer an, einen anderen Computer oder ein anderes Gerät zu verwenden und sich mit dem Autorisierungsserver zu verbinden, um die Zugriffsanfrage zu genehmigen. Da das Protokoll Clients unterstützt, die keine eingehenden Anfragen empfangen können, fragen Clients den Autorisierungsserver wiederholt ab, bis der Endbenutzer den Genehmigungsprozess abgeschlossen hat.
Der Geräteclient wählt typischerweise die zu unterstützenden Autorisierungsserver aus (d.h. seinen eigenen Autorisierungsserver oder die von Anbietern, mit denen er Beziehungen hat). Es ist üblich, dass der Geräteclient nur einen Autorisierungsserver unterstützt, wie im Fall einer TV-Anwendung für einen bestimmten Medienanbieter, die nur den Autorisierungsserver dieses Medienanbieters unterstützt. Der Benutzer hat möglicherweise noch keine etablierte Beziehung zu diesem Autorisierungsanbieter, obwohl während des Autorisierungsablaufs potenziell eine eingerichtet werden kann.
+----------+ +----------------+
| |>---(A)-- Client Identifier --->| |
| | | |
| |<---(B)-- Device Code, ---<| |
| | User Code, | |
| Device | & Verification URI | |
| Client | | |
| | [polling] | |
| |>---(E)-- Device Code --->| |
| | & Client Identifier | |
| | | Authorization |
| |<---(F)-- Access Token ---<| Server |
+----------+ (& Optional Refresh Token) | |
v | |
: | |
(C) User Code & Verification URI | |
: | |
v | |
+----------+ | |
| End User | | |
| at |<---(D)-- End user reviews --->| |
| Browser | authorization request | |
+----------+ +----------------+
Abbildung 1: Geräteautorisierungsablauf
Der in Abbildung 1 dargestellte Geräteautorisierungsablauf umfasst die folgenden Schritte:
(A) Der Client fordert Zugriff vom Autorisierungsserver an und fügt seinen Client-Identifikator in die Anfrage ein.
(B) Der Autorisierungsserver stellt einen Gerätecode und einen Endbenutzercode aus und stellt den Endbenutzer-Verifizierungs-URI bereit.
(C) Der Client weist den Endbenutzer an, einen Benutzeragenten auf einem anderen Gerät zu verwenden und den bereitgestellten Endbenutzer-Verifizierungs-URI zu besuchen. Der Client stellt dem Benutzer den Endbenutzercode zur Eingabe bereit, um die Autorisierungsanfrage zu überprüfen.
(D) Der Autorisierungsserver authentifiziert den Endbenutzer (über den Benutzeragenten) und fordert den Benutzer auf, den vom Geräteclient bereitgestellten Benutzercode einzugeben. Der Autorisierungsserver validiert den vom Benutzer bereitgestellten Benutzercode und fordert den Benutzer auf, die Anfrage zu akzeptieren oder abzulehnen.
(E) Während der Endbenutzer die Anfrage des Clients überprüft (Schritt D), fragt der Client wiederholt den Autorisierungsserver ab, um herauszufinden, ob der Benutzer den Benutzerautorisierungsschritt abgeschlossen hat. Der Client fügt den Gerätecode und seinen Client-Identifikator ein.
(F) Der Autorisierungsserver validiert den vom Client bereitgestellten Gerätecode und antwortet mit dem Zugriffstoken, wenn dem Client Zugriff gewährt wird, einem Fehler, wenn ihm der Zugriff verweigert wird, oder einer Anzeige, dass der Client weiter abfragen sollte.
🇮🇹 Italiano
Questa estensione del protocollo OAuth 2.0 [RFC6749] consente ai client OAuth di richiedere l'autorizzazione dell'utente da applicazioni su dispositivi che hanno capacità di input limitate o mancano di un browser adeguato. Tali dispositivi includono smart TV, console multimediali, cornici fotografiche e stampanti, che mancano di un metodo di input facile o di un browser adeguato richiesto per le interazioni OAuth tradizionali. Il flusso di autorizzazione definito da questa specifica, a volte chiamato "flusso del dispositivo", istruisce l'utente a rivedere la richiesta di autorizzazione su un dispositivo secondario, come uno smartphone, che ha le capacità di input e browser necessarie per completare l'interazione dell'utente.
La concessione di autorizzazione del dispositivo non è destinata a sostituire OAuth basato su browser nelle app native su dispositivi capaci come gli smartphone. Queste app dovrebbero seguire le pratiche specificate in "OAuth 2.0 for Native Apps" [RFC8252].
I requisiti operativi per l'utilizzo di questo tipo di concessione di autorizzazione sono:
(1) Il dispositivo è già connesso a Internet.
(2) Il dispositivo è in grado di effettuare richieste HTTPS in uscita.
(3) Il dispositivo è in grado di visualizzare o comunicare in altro modo un URI e una sequenza di codici all'utente.
(4) L'utente ha un dispositivo secondario (ad esempio, personal computer o smartphone) da cui può elaborare la richiesta.
Poiché la concessione di autorizzazione del dispositivo non richiede comunicazione bidirezionale tra il client OAuth sul dispositivo e l'agente utente (a differenza di altri tipi di concessione OAuth 2, come i tipi di concessione del codice di autorizzazione e implicita), supporta diversi casi d'uso che non possono essere serviti da questi altri approcci.
Invece di interagire direttamente con l'agente utente dell'utente finale (cioè il browser), il client del dispositivo istruisce l'utente finale a utilizzare un altro computer o dispositivo e connettersi al server di autorizzazione per approvare la richiesta di accesso. Poiché il protocollo supporta client che non possono ricevere richieste in ingresso, i client interrogano ripetutamente il server di autorizzazione fino a quando l'utente finale completa il processo di approvazione.
Il client del dispositivo sceglie tipicamente l'insieme di server di autorizzazione da supportare (cioè il proprio server di autorizzazione o quelli dei fornitori con cui ha relazioni). È comune che il client del dispositivo supporti solo un server di autorizzazione, come nel caso di un'applicazione TV per un fornitore di contenuti multimediali specifico che supporta solo il server di autorizzazione di quel fornitore di contenuti multimediali. L'utente potrebbe non avere ancora una relazione stabilita con quel fornitore di autorizzazione, sebbene una possa essere potenzialmente impostata durante il flusso di autorizzazione.
+----------+ +----------------+
| |>---(A)-- Client Identifier --->| |
| | | |
| |<---(B)-- Device Code, ---<| |
| | User Code, | |
| Device | & Verification URI | |
| Client | | |
| | [polling] | |
| |>---(E)-- Device Code --->| |
| | & Client Identifier | |
| | | Authorization |
| |<---(F)-- Access Token ---<| Server |
+----------+ (& Optional Refresh Token) | |
v | |
: | |
(C) User Code & Verification URI | |
: | |
v | |
+----------+ | |
| End User | | |
| at |<---(D)-- End user reviews --->| |
| Browser | authorization request | |
+----------+ +----------------+
Figura 1: Flusso di autorizzazione del dispositivo
Il flusso di autorizzazione del dispositivo illustrato nella Figura 1 include i seguenti passaggi:
(A) Il client richiede l'accesso dal server di autorizzazione e include il suo identificatore client nella richiesta.
(B) Il server di autorizzazione rilascia un codice dispositivo e un codice utente finale e fornisce l'URI di verifica dell'utente finale.
(C) Il client istruisce l'utente finale a utilizzare un agente utente su un altro dispositivo e visitare l'URI di verifica dell'utente finale fornito. Il client fornisce all'utente il codice utente finale da inserire per rivedere la richiesta di autorizzazione.
(D) Il server di autorizzazione autentica l'utente finale (tramite l'agente utente) e richiede all'utente di inserire il codice utente fornito dal client del dispositivo. Il server di autorizzazione convalida il codice utente fornito dall'utente e richiede all'utente di accettare o rifiutare la richiesta.
(E) Mentre l'utente finale esamina la richiesta del client (passaggio D), il client interroga ripetutamente il server di autorizzazione per scoprire se l'utente ha completato il passaggio di autorizzazione dell'utente. Il client include il codice dispositivo e il suo identificatore client.
(F) Il server di autorizzazione convalida il codice dispositivo fornito dal client e risponde con il token di accesso se al client viene concesso l'accesso, un errore se viene negato l'accesso, o un'indicazione che il client dovrebbe continuare a interrogare.