Skip to main content

3.5. Device Access Token Response (设备访问令牌响应)

🇬🇧 English​

If the user has approved the grant, the token endpoint responds with a success response defined in Section 5.1 of [RFC6749]; otherwise, it responds with an error, as defined in Section 5.2 of [RFC6749].

In addition to the error codes defined in Section 5.2 of [RFC6749], the following error codes are specified for use with the device authorization grant in token endpoint responses:

authorization_pending

  • The authorization request is still pending as the end user hasn't yet completed the user-interaction steps (Section 3.3). The client SHOULD repeat the access token request to the token endpoint (a process known as polling). Before each new request, the client MUST wait at least the number of seconds specified by the "interval" parameter of the device authorization response (see Section 3.2), or 5 seconds if none was provided, and respect any increase in the polling interval required by the "slow_down" error.

slow_down

  • A variant of "authorization_pending", the authorization request is still pending and polling should continue, but the interval MUST be increased by 5 seconds for this and all subsequent requests.

access_denied

  • The authorization request was denied.

expired_token

  • The "device_code" has expired, and the device authorization session has concluded. The client MAY commence a new device authorization request but SHOULD wait for user interaction before restarting to avoid unnecessary polling.

The "authorization_pending" and "slow_down" error codes define particularly unique behavior, as they indicate that the OAuth client should continue to poll the token endpoint by repeating the token request (implementing the precise behavior defined above). If the client receives an error response with any other error code, it MUST stop polling and SHOULD react accordingly, for example, by displaying an error to the user.

On encountering a connection timeout, clients MUST unilaterally reduce their polling frequency before retrying. The use of an exponential backoff algorithm to achieve this, such as doubling the polling interval on each such connection timeout, is RECOMMENDED.

The assumption of this specification is that the separate device on which the user is authorizing the request does not have a way to communicate back to the device with the OAuth client. This protocol only requires a one-way channel in order to maximize the viability of the protocol in restricted environments, like an application running on a TV that is only capable of outbound requests. If a return channel were to exist for the chosen user-interaction interface, then the device MAY wait until notified on that channel that the user has completed the action before initiating the token request (as an alternative to polling). Such behavior is, however, outside the scope of this specification.

🇨🇳 中文​

如果用户已批准授权,令牌端点以 [RFC6749] 第 5.1 节中定义的成功响应进行响应;否则,它以 [RFC6749] 第 5.2 节中定义的错误进行响应。

除了 [RFC6749] 第 5.2 节中定义的错误代码外,以下错误代码专门用于令牌端点响应中的设备授权许可:

authorization_pending (授权待处理)

  • 授权请求仍在待处理中,因为最终用户尚未完成用户交互步骤(第 3.3 节)。客户端应该 (SHOULD) 向令牌端点重复访问令牌请求(称为轮询的过程)。在每个新请求之前,客户端必须 (MUST) 至少等待设备授权响应的 "interval" 参数指定的秒数(参见第 3.2 节),如果未提供则为 5 秒,并遵守 "slow_down" 错误要求的轮询间隔的任何增加。

slow_down (降低速度)

  • "authorization_pending" 的变体,授权请求仍在待处理中且轮询应继续,但对于此请求和所有后续请求,间隔必须 (MUST) 增加 5 秒。

access_denied (访问被拒绝)

  • 授权请求被拒绝。

expired_token (令牌已过期)

  • "device_code" 已过期,设备授权会话已结束。客户端可以 (MAY) 开始新的设备授权请求,但应该 (SHOULD) 在重新启动之前等待用户交互以避免不必要的轮询。

"authorization_pending" 和 "slow_down" 错误代码定义了特别独特的行为,因为它们表明 OAuth 客户端应该通过重复令牌请求(实现上述定义的精确行为)继续轮询令牌端点。如果客户端收到带有任何其他错误代码的错误响应,它必须 (MUST) 停止轮询,并应该 (SHOULD) 做出相应反应,例如向用户显示错误。

遇到连接超时时,客户端必须 (MUST) 在重试之前单方面降低其轮询频率。推荐 (RECOMMENDED) 使用指数退避算法来实现这一点,例如在每次此类连接超时时将轮询间隔加倍。

本规范的假设是,用户授权请求的单独设备无法与具有 OAuth 客户端的设备进行通信。此协议仅需要单向通道,以最大化协议在受限环境中的可行性,例如在电视上运行的应用程序仅能够发出出站请求。如果为所选的用户交互接口存在返回通道,则设备可以 (MAY) 等到在该通道上收到用户已完成操作的通知后再发起令牌请求(作为轮询的替代方案)。但是,此类行为超出了本规范的范围。

🇯🇵 日本語​

ユーザーがグラントを承認した場合、トークンエンドポイントは [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)(ポーリングの代替として)。ただし、このような動作はこの仕様の範囲外です。

🇫🇷 Français​

Si l'utilisateur a approuvé l'autorisation, le point de terminaison de jeton répond avec une réponse de succès définie dans la Section 5.1 de [RFC6749]; sinon, il répond avec une erreur, comme défini dans la Section 5.2 de [RFC6749].

En plus des codes d'erreur définis dans la Section 5.2 de [RFC6749], les codes d'erreur suivants sont spécifiés pour une utilisation avec l'autorisation d'appareil dans les réponses du point de terminaison de jeton:

authorization_pending (autorisation en attente)

  • La demande d'autorisation est toujours en attente car l'utilisateur final n'a pas encore terminé les étapes d'interaction utilisateur (Section 3.3). Le client DEVRAIT répéter la demande de jeton d'accès au point de terminaison de jeton (un processus connu sous le nom de sondage). Avant chaque nouvelle demande, le client DOIT attendre au moins le nombre de secondes spécifié par le paramètre "interval" de la réponse d'autorisation de l'appareil (voir Section 3.2), ou 5 secondes si aucun n'a été fourni, et respecter toute augmentation de l'intervalle de sondage requise par l'erreur "slow_down".

slow_down (ralentir)

  • Une variante de "authorization_pending", la demande d'autorisation est toujours en attente et le sondage devrait continuer, mais l'intervalle DOIT être augmenté de 5 secondes pour cette demande et toutes les demandes ultérieures.

access_denied (accès refusé)

  • La demande d'autorisation a été refusée.

expired_token (jeton expiré)

  • Le "device_code" a expiré et la session d'autorisation de l'appareil s'est terminée. Le client PEUT commencer une nouvelle demande d'autorisation d'appareil mais DEVRAIT attendre l'interaction de l'utilisateur avant de redémarrer pour éviter un sondage inutile.

Les codes d'erreur "authorization_pending" et "slow_down" définissent un comportement particulièrement unique, car ils indiquent que le client OAuth devrait continuer à sonder le point de terminaison de jeton en répétant la demande de jeton (en mettant en œuvre le comportement précis défini ci-dessus). Si le client reçoit une réponse d'erreur avec tout autre code d'erreur, il DOIT arrêter le sondage et DEVRAIT réagir en conséquence, par exemple en affichant une erreur à l'utilisateur.

En cas de délai d'attente de connexion, les clients DOIVENT réduire unilatéralement leur fréquence de sondage avant de réessayer. L'utilisation d'un algorithme de backoff exponentiel pour y parvenir, tel que doubler l'intervalle de sondage à chaque délai d'attente de connexion, est RECOMMANDÉE.

L'hypothèse de cette spécification est que l'appareil séparé sur lequel l'utilisateur autorise la demande n'a pas de moyen de communiquer avec l'appareil avec le client OAuth. Ce protocole ne nécessite qu'un canal unidirectionnel afin de maximiser la viabilité du protocole dans des environnements restreints, comme une application fonctionnant sur une télévision qui n'est capable que de demandes sortantes. Si un canal de retour devait exister pour l'interface d'interaction utilisateur choisie, alors l'appareil PEUT attendre d'être notifié sur ce canal que l'utilisateur a terminé l'action avant d'initier la demande de jeton (comme alternative au sondage). Un tel comportement est toutefois en dehors de la portée de cette spécification.

🇩🇪 Deutsch​

Wenn der Benutzer die Genehmigung erteilt hat, antwortet der Token-Endpunkt mit einer Erfolgsantwort, die in Abschnitt 5.1 von [RFC6749] definiert ist; andernfalls antwortet er mit einem Fehler, wie in Abschnitt 5.2 von [RFC6749] definiert.

Zusätzlich zu den in Abschnitt 5.2 von [RFC6749] definierten Fehlercodes sind die folgenden Fehlercodes für die Verwendung mit der Geräteautorisierungsgenehmigung in Token-Endpunkt-Antworten spezifiziert:

authorization_pending (Autorisierung ausstehend)

  • Die Autorisierungsanfrage steht noch aus, da der Endbenutzer die Benutzerinteraktionsschritte (Abschnitt 3.3) noch nicht abgeschlossen hat. Der Client SOLLTE die Zugriffstokenanfrage an den Token-Endpunkt wiederholen (ein als Polling bekannter Prozess). Vor jeder neuen Anfrage MUSS der Client mindestens die Anzahl von Sekunden warten, die durch den "interval"-Parameter der Geräteautorisierungsantwort angegeben ist (siehe Abschnitt 3.2), oder 5 Sekunden, wenn keiner angegeben wurde, und jede Erhöhung des Polling-Intervalls beachten, die durch den "slow_down"-Fehler erforderlich ist.

slow_down (verlangsamen)

  • Eine Variante von "authorization_pending". Die Autorisierungsanfrage steht noch aus und das Polling sollte fortgesetzt werden, aber das Intervall MUSS für diese und alle nachfolgenden Anfragen um 5 Sekunden erhöht werden.

access_denied (Zugriff verweigert)

  • Die Autorisierungsanfrage wurde abgelehnt.

expired_token (Token abgelaufen)

  • Der "device_code" ist abgelaufen und die Geräteautorisierungssitzung wurde beendet. Der Client KANN eine neue Geräteautorisierungsanfrage starten, SOLLTE jedoch vor dem Neustart auf Benutzerinteraktion warten, um unnötiges Polling zu vermeiden.

Die Fehlercodes "authorization_pending" und "slow_down" definieren ein besonders einzigartiges Verhalten, da sie anzeigen, dass der OAuth-Client weiterhin den Token-Endpunkt abfragen sollte, indem er die Tokenanfrage wiederholt (wobei das oben definierte präzise Verhalten implementiert wird). Wenn der Client eine Fehlerantwort mit einem anderen Fehlercode erhält, MUSS er das Polling stoppen und SOLLTE entsprechend reagieren, z.B. durch Anzeige eines Fehlers an den Benutzer.

Bei einer Verbindungszeitüberschreitung MÜSSEN Clients ihre Polling-Frequenz einseitig reduzieren, bevor sie es erneut versuchen. Die Verwendung eines exponentiellen Backoff-Algorithmus, um dies zu erreichen, wie z.B. die Verdoppelung des Polling-Intervalls bei jeder solchen Verbindungszeitüberschreitung, wird EMPFOHLEN.

Die Annahme dieser Spezifikation ist, dass das separate Gerät, auf dem der Benutzer die Anfrage autorisiert, keine Möglichkeit hat, mit dem Gerät mit dem OAuth-Client zu kommunizieren. Dieses Protokoll erfordert nur einen Einwegkanal, um die Durchführbarkeit des Protokolls in eingeschränkten Umgebungen zu maximieren, wie z.B. eine auf einem Fernseher laufende Anwendung, die nur zu ausgehenden Anfragen fähig ist. Wenn ein Rückkanal für die gewählte Benutzerinteraktionsschnittstelle existieren würde, KANN das Gerät warten, bis es über diesen Kanal benachrichtigt wird, dass der Benutzer die Aktion abgeschlossen hat, bevor es die Tokenanfrage initiiert (als Alternative zum Polling). Ein solches Verhalten liegt jedoch außerhalb des Anwendungsbereichs dieser Spezifikation.

🇮🇹 Italiano​

Se l'utente ha approvato la concessione, l'endpoint token risponde con una risposta di successo definita nella Sezione 5.1 di [RFC6749]; altrimenti, risponde con un errore, come definito nella Sezione 5.2 di [RFC6749].

Oltre ai codici di errore definiti nella Sezione 5.2 di [RFC6749], i seguenti codici di errore sono specificati per l'uso con la concessione di autorizzazione del dispositivo nelle risposte dell'endpoint token:

authorization_pending (autorizzazione in sospeso)

  • La richiesta di autorizzazione è ancora in sospeso poiché l'utente finale non ha ancora completato i passaggi di interazione utente (Sezione 3.3). Il client DOVREBBE ripetere la richiesta di token di accesso all'endpoint token (un processo noto come polling). Prima di ogni nuova richiesta, il client DEVE attendere almeno il numero di secondi specificato dal parametro "interval" della risposta di autorizzazione del dispositivo (vedere Sezione 3.2), o 5 secondi se non ne è stato fornito alcuno, e rispettare qualsiasi aumento dell'intervallo di polling richiesto dall'errore "slow_down".

slow_down (rallentare)

  • Una variante di "authorization_pending", la richiesta di autorizzazione è ancora in sospeso e il polling dovrebbe continuare, ma l'intervallo DEVE essere aumentato di 5 secondi per questa e tutte le richieste successive.

access_denied (accesso negato)

  • La richiesta di autorizzazione è stata negata.

expired_token (token scaduto)

  • Il "device_code" è scaduto e la sessione di autorizzazione del dispositivo si è conclusa. Il client PUÒ iniziare una nuova richiesta di autorizzazione del dispositivo ma DOVREBBE attendere l'interazione dell'utente prima di riavviare per evitare polling non necessari.

I codici di errore "authorization_pending" e "slow_down" definiscono un comportamento particolarmente unico, poiché indicano che il client OAuth dovrebbe continuare a interrogare l'endpoint token ripetendo la richiesta di token (implementando il comportamento preciso definito sopra). Se il client riceve una risposta di errore con qualsiasi altro codice di errore, DEVE interrompere il polling e DOVREBBE reagire di conseguenza, ad esempio visualizzando un errore all'utente.

In caso di timeout della connessione, i client DEVONO ridurre unilateralmente la loro frequenza di polling prima di riprovare. L'uso di un algoritmo di backoff esponenziale per raggiungere questo obiettivo, come raddoppiare l'intervallo di polling ad ogni timeout di connessione, è RACCOMANDATO.

L'ipotesi di questa specifica è che il dispositivo separato su cui l'utente sta autorizzando la richiesta non abbia un modo per comunicare al dispositivo con il client OAuth. Questo protocollo richiede solo un canale unidirezionale per massimizzare la fattibilità del protocollo in ambienti limitati, come un'applicazione in esecuzione su una TV che è in grado solo di richieste in uscita. Se dovesse esistere un canale di ritorno per l'interfaccia di interazione utente scelta, allora il dispositivo PUÒ attendere fino a quando non viene notificato su quel canale che l'utente ha completato l'azione prima di avviare la richiesta di token (come alternativa al polling). Tale comportamento è, tuttavia, al di fuori dell'ambito di questa specifica.

Last updated on