Internet Engineering Task Force (IETF) W. Denniss
Request for Comments: 8628 Google
Category: Standards Track J. Bradley
ISSN: 2070-1721 Ping Identity
M. Jones
Microsoft
H. Tschofenig
ARM Limited
August 2019
Internet Engineering Task Force (IETF) W. Denniss
Request for Comments: 8628 Google
Category: Standards Track J. Bradley
ISSN: 2070-1721 Ping Identity
M. Jones
Microsoft
H. Tschofenig
ARM Limited
August 2019
OAuth 2.0 Device Authorization Grant
OAuth 2.0设备授权授予
Abstract
摘要
The OAuth 2.0 device authorization grant is designed for Internet-connected devices that either lack a browser to perform a user-agent-based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources by using a user agent on a separate device.
OAuth 2.0设备授权授权是为Internet连接的设备设计的，这些设备要么没有浏览器来执行基于用户代理的授权，要么输入受限到要求用户输入文本以便在授权流期间进行身份验证是不切实际的程度。它使此类设备（如智能电视、媒体控制台、数字相框和打印机）上的OAuth客户端能够通过在单独的设备上使用用户代理获得访问受保护资源的用户授权。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8628.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8628.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Device Authorization Request . . . . . . . . . . . . . . 5
3.2. Device Authorization Response . . . . . . . . . . . . . . 7
3.3. User Interaction . . . . . . . . . . . . . . . . . . . . 8
3.3.1. Non-Textual Verification URI Optimization . . . . . . 9
3.4. Device Access Token Request . . . . . . . . . . . . . . . 10
3.5. Device Access Token Response . . . . . . . . . . . . . . 11
4. Discovery Metadata . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5.1. User Code Brute Forcing . . . . . . . . . . . . . . . . . 12
5.2. Device Code Brute Forcing . . . . . . . . . . . . . . . . 13
5.3. Device Trustworthiness . . . . . . . . . . . . . . . . . 13
5.4. Remote Phishing . . . . . . . . . . . . . . . . . . . . . 14
5.5. Session Spying . . . . . . . . . . . . . . . . . . . . . 15
5.6. Non-Confidential Clients . . . . . . . . . . . . . . . . 15
5.7. Non-Visual Code Transmission . . . . . . . . . . . . . . 15
6. Usability Considerations . . . . . . . . . . . . . . . . . . 16
6.1. User Code Recommendations . . . . . . . . . . . . . . . . 16
6.2. Non-Browser User Interaction . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7.1. OAuth Parameter Registration . . . . . . . . . . . . . . 17
7.2. OAuth URI Registration . . . . . . . . . . . . . . . . . 17
7.3. OAuth Extensions Error Registration . . . . . . . . . . . 18
7.4. OAuth Authorization Server Metadata . . . . . . . . . . . 18
8. Normative References . . . . . . . . . . . . . . . . . . . . 19
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Device Authorization Request . . . . . . . . . . . . . . 5
3.2. Device Authorization Response . . . . . . . . . . . . . . 7
3.3. User Interaction . . . . . . . . . . . . . . . . . . . . 8
3.3.1. Non-Textual Verification URI Optimization . . . . . . 9
3.4. Device Access Token Request . . . . . . . . . . . . . . . 10
3.5. Device Access Token Response . . . . . . . . . . . . . . 11
4. Discovery Metadata . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5.1. User Code Brute Forcing . . . . . . . . . . . . . . . . . 12
5.2. Device Code Brute Forcing . . . . . . . . . . . . . . . . 13
5.3. Device Trustworthiness . . . . . . . . . . . . . . . . . 13
5.4. Remote Phishing . . . . . . . . . . . . . . . . . . . . . 14
5.5. Session Spying . . . . . . . . . . . . . . . . . . . . . 15
5.6. Non-Confidential Clients . . . . . . . . . . . . . . . . 15
5.7. Non-Visual Code Transmission . . . . . . . . . . . . . . 15
6. Usability Considerations . . . . . . . . . . . . . . . . . . 16
6.1. User Code Recommendations . . . . . . . . . . . . . . . . 16
6.2. Non-Browser User Interaction . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7.1. OAuth Parameter Registration . . . . . . . . . . . . . . 17
7.2. OAuth URI Registration . . . . . . . . . . . . . . . . . 17
7.3. OAuth Extensions Error Registration . . . . . . . . . . . 18
7.4. OAuth Authorization Server Metadata . . . . . . . . . . . 18
8. Normative References . . . . . . . . . . . . . . . . . . . . 19
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
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.
此OAuth 2.0[RFC6749]协议扩展使OAuth客户端能够从输入能力有限或缺少合适浏览器的设备上的应用程序请求用户授权。这类设备包括智能电视、媒体控制台、相框和打印机，这些设备缺乏传统OAuth交互所需的简单输入方法或合适的浏览器。本规范定义的授权流（有时称为“设备流”）指示用户在辅助设备（如智能手机）上查看授权请求，该辅助设备具有完成用户交互所需的输入和浏览器功能。
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].
设备授权授权并非旨在取代智能手机等设备上本机应用程序中基于浏览器的OAuth。这些应用程序应遵循“OAuth 2.0本机应用程序”[RFC8252]中指定的实践。
The operating requirements for using this authorization grant type are:
使用此授权授予类型的操作要求如下：
(1) The device is already connected to the Internet.
(1) 该设备已连接到Internet。
(2) The device is able to make outbound HTTPS requests.
(2) 设备能够发出出站HTTPS请求。
(3) The device is able to display or otherwise communicate a URI and code sequence to the user.
(3) 该设备能够向用户显示或以其他方式传递URI和代码序列。
(4) The user has a secondary device (e.g., personal computer or smartphone) from which they can process the request.
(4) 用户有一个辅助设备（如个人电脑或智能手机），可以从中处理请求。
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.
由于设备授权授权不需要设备上的OAuth客户端和用户代理之间的双向通信（与其他OAuth 2授权类型不同，如授权代码和隐式授权类型），因此它支持一些其他方法无法提供的用例。
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 | |
+----------+ +----------------+
+----------+ +----------------+
| |>---(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
图1：设备授权流程
The device authorization flow illustrated in Figure 1 includes the following steps:
图1所示的设备授权流程包括以下步骤：
(A) The client requests access from the authorization server and includes its client identifier in the request.
（A） 客户端从授权服务器请求访问权限，并在请求中包含其客户端标识符。
(B) The authorization server issues a device code and an end-user code and provides the end-user verification URI.
（B） 授权服务器发出设备代码和最终用户代码，并提供最终用户验证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.
（C） 客户端指示最终用户在另一个设备上使用用户代理，并访问提供的最终用户验证URI。客户端向用户提供要输入的最终用户代码，以便查看授权请求。
(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.
（D） 授权服务器（通过用户代理）验证最终用户，并提示用户输入设备客户端提供的用户代码。授权服务器验证用户提供的用户代码，并提示用户接受或拒绝请求。
(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.
（E） 当最终用户查看客户端的请求（步骤D）时，客户端反复轮询授权服务器，以确定用户是否完成了用户授权步骤。客户端包括设备代码及其客户端标识符。
(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.
（F） 授权服务器验证客户端提供的设备代码，如果客户端被授予访问权限，则使用访问令牌进行响应；如果客户端被拒绝访问，则返回错误；或者指示客户端应继续轮询。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
This specification defines a new OAuth endpoint: the device authorization endpoint. This is separate from the OAuth authorization endpoint defined in [RFC6749] with which the user interacts via a user agent (i.e., a browser). By comparison, when using the device authorization endpoint, the OAuth client on the device interacts with the authorization server directly without presenting the request in a user agent, and the end user authorizes the request on a separate device. This interaction is defined as follows.
此规范定义了一个新的OAuth端点：设备授权端点。这与[RFC6749]中定义的OAuth授权端点不同，用户通过用户代理（即浏览器）与该端点进行交互。相比之下，当使用设备授权端点时，设备上的OAuth客户端直接与授权服务器交互，而不在用户代理中显示请求，最终用户在单独的设备上授权请求。这种相互作用的定义如下。
The client initiates the authorization flow by requesting a set of verification codes from the authorization server by making an HTTP "POST" request to the device authorization endpoint.
客户端通过向设备授权端点发出HTTP“POST”请求，从授权服务器请求一组验证代码，从而启动授权流。
The client makes a device authorization request to the device authorization endpoint by including the following parameters using the "application/x-www-form-urlencoded" format, per Appendix B of [RFC6749], with a character encoding of UTF-8 in the HTTP request entity-body:
根据[RFC6749]的附录B，客户端使用“应用程序/x-www-form-URLCoded”格式，在HTTP请求实体体中使用UTF-8字符编码，通过包括以下参数，向设备授权端点发出设备授权请求：
client_id REQUIRED if the client is not authenticating with the authorization server as described in Section 3.2.1. of [RFC6749]. The client identifier as described in Section 2.2 of [RFC6749].
如果客户端未按照第3.2.1节所述使用授权服务器进行身份验证，则需要客户端id。属于[RFC6749]。[RFC6749]第2.2节所述的客户标识符。
scope OPTIONAL. The scope of the access request as defined by Section 3.3 of [RFC6749].
范围可选。[RFC6749]第3.3节定义的访问请求范围。
For example, the client makes the following HTTPS request:
例如，客户端发出以下HTTPS请求：
POST /device_authorization HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
POST /device_authorization HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
client_id=1406020730&scope=example_scope
客户id=1406020730&范围=示例范围
All requests from the device MUST use the Transport Layer Security (TLS) protocol [RFC8446] and implement the best practices of BCP 195 [RFC7525].
来自设备的所有请求必须使用传输层安全（TLS）协议[RFC8446]，并实施BCP 195[RFC7525]的最佳实践。
Parameters sent without a value MUST be treated as if they were omitted from the request. The authorization server MUST ignore unrecognized request parameters. Request and response parameters MUST NOT be included more than once.
发送时不带值的参数必须视为从请求中省略了它们。授权服务器必须忽略无法识别的请求参数。请求和响应参数不能包含多次。
The client authentication requirements of Section 3.2.1 of [RFC6749] apply to requests on this endpoint, which means that confidential clients (those that have established client credentials) authenticate in the same manner as when making requests to the token endpoint, and public clients provide the "client_id" parameter to identify themselves.
[RFC6749]第3.2.1节中的客户端身份验证要求适用于此端点上的请求，这意味着机密客户端（已建立客户端凭据的客户端）以与向令牌端点发出请求时相同的方式进行身份验证，并且公共客户端提供“client_id”参数来标识自己。
Due to the polling nature of this protocol (as specified in Section 3.4), care is needed to avoid overloading the capacity of the token endpoint. To avoid unneeded requests on the token endpoint, the client SHOULD only commence a device authorization request when prompted by the user and not automatically, such as when the app starts or when the previous authorization session expires or fails.
由于该协议的轮询性质（如第3.4节所述），需要注意避免令牌端点的容量过载。为了避免令牌端点上出现不必要的请求，客户端应仅在用户提示时启动设备授权请求，而不是自动启动设备授权请求，例如应用程序启动时或前一个授权会话过期或失败时。
In response, the authorization server generates a unique device verification code and an end-user code that are valid for a limited time and includes them in the HTTP response body using the "application/json" format [RFC8259] with a 200 (OK) status code. The response contains the following parameters:
作为响应，授权服务器生成在有限时间内有效的唯一设备验证代码和最终用户代码，并使用带有200（OK）状态代码的“应用程序/json”格式[RFC8259]将其包含在HTTP响应正文中。响应包含以下参数：
device_code REQUIRED. The device verification code.
需要设备代码。设备验证码。
user_code REQUIRED. The end-user verification code.
需要用户代码。最终用户验证码。
verification_uri REQUIRED. The end-user verification URI on the authorization server. The URI should be short and easy to remember as end users will be asked to manually type it into their user agent.
需要验证uri。授权服务器上的最终用户验证URI。URI应该简短且易于记忆，因为最终用户将被要求手动将其键入其用户代理。
verification_uri_complete OPTIONAL. A verification URI that includes the "user_code" (or other information with the same function as the "user_code"), which is designed for non-textual transmission.
验证\u uri\u完成可选。一种验证URI，包括“用户代码”（或与“用户代码”具有相同功能的其他信息），设计用于非文本传输。
expires_in REQUIRED. The lifetime in seconds of the "device_code" and "user_code".
需要在中过期。“设备\u代码”和“用户\u代码”的生存期（以秒为单位）。
interval OPTIONAL. The minimum amount of time in seconds that the client SHOULD wait between polling requests to the token endpoint. If no value is provided, clients MUST use 5 as the default.
间隔时间可选。客户端在对令牌终结点的轮询请求之间应等待的最短时间（秒）。如果未提供值，客户端必须使用5作为默认值。
For example:
例如：
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
"device_code": "GmRhmhcxhwAzkoEqiMEg_DnyEysNkuNhszIySk9eS",
"user_code": "WDJB-MJHT",
"verification_uri": "https://example.com/device",
"verification_uri_complete":
"https://example.com/device?user_code=WDJB-MJHT",
"expires_in": 1800,
"interval": 5
}
{
"device_code": "GmRhmhcxhwAzkoEqiMEg_DnyEysNkuNhszIySk9eS",
"user_code": "WDJB-MJHT",
"verification_uri": "https://example.com/device",
"verification_uri_complete":
"https://example.com/device?user_code=WDJB-MJHT",
"expires_in": 1800,
"interval": 5
}
In the event of an error (such as an invalidly configured client), the authorization server responds in the same way as the token endpoint specified in Section 5.2 of [RFC6749].
如果出现错误（例如配置无效的客户端），授权服务器将以与[RFC6749]第5.2节中指定的令牌端点相同的方式响应。
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.
在接收到成功的授权响应后，客户端显示或以其他方式将“用户代码”和“验证uri”传达给最终用户，并指示他们访问辅助设备上的用户代理中的uri（例如，在其移动电话上的浏览器中）并输入用户代码。
+-----------------------------------------------+
| |
| Using a browser on another device, visit: |
| https://example.com/device |
| |
| And enter the code: |
| WDJB-MJHT |
| |
+-----------------------------------------------+
+-----------------------------------------------+
| |
| Using a browser on another device, visit: |
| https://example.com/device |
| |
| And enter the code: |
| WDJB-MJHT |
| |
+-----------------------------------------------+
Figure 2: Example User Instruction
图2：示例用户指令
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.
授权用户导航到“验证uri”，并在受TLS保护的安全[RFC8446]会话中与授权服务器进行身份验证。授权服务器通过输入客户端提供的“用户代码”提示最终用户识别设备授权会话。然后，授权服务器应通知用户他们正在执行的操作，并要求他们批准或拒绝请求。一旦用户交互完成，服务器将指示用户返回其设备。
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.
在用户交互期间，设备使用“设备_代码”连续轮询令牌端点，如第3.4节所述，直到用户完成交互、代码过期或出现另一个错误。“设备代码”并非直接针对最终用户；因此，在交互过程中不应显示它，以避免混淆最终用户。
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.
支持此规范的授权服务器必须实现一个用户交互序列，该序列从用户导航到“验证uri”开始，并在交互过程中的某个阶段继续提供“用户代码”。除此之外，用户交互的确切顺序和实现取决于授权服务器；例如，授权服务器可以允许新用户在授权流期间注册帐户，或者添加额外的安全验证步骤。
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.
不建议授权服务器在验证URI（“验证URI”）中包含用户代码（“用户代码”），因为这会增加用户必须键入的URI的长度和复杂性。虽然用户仍必须键入类似数量的字符，并将“用户代码”分隔开，但一旦他们成功导航到“验证uri”，授权服务器可以突出显示输入代码中的任何错误，以改善用户体验。下一节将记录用户与“verification_uri_complete”的交互，该交互旨在携带这两条信息。
When "verification_uri_complete" is included in the authorization response (Section 3.2), clients MAY present this URI in a non-textual manner using any method that results in the browser being opened with the URI, such as with QR (Quick Response) codes or NFC (Near Field Communication), to save the user from typing the URI.
当授权响应（第3.2节）中包含“验证uri_完成”时，客户端可以使用导致浏览器以uri打开的任何方法（如QR（快速响应）代码或NFC（近场通信））以非文本方式呈现此uri，以避免用户键入uri。
For usability reasons, it is RECOMMENDED for clients to still display the textual verification URI ("verification_uri") for users who are not able to use such a shortcut. Clients MUST still display the "user_code", as the authorization server will require the user to confirm it to disambiguate devices or as remote phishing mitigation (see Section 5.4).
出于可用性原因，建议客户端仍然为无法使用这种快捷方式的用户显示文本验证URI（“验证URI”）。客户端仍必须显示“用户代码”，因为授权服务器将要求用户确认该代码以消除设备歧义或作为远程钓鱼缓解措施（见第5.4节）。
If the user starts the user interaction by navigating to "verification_uri_complete", then the user interaction described in Section 3.3 is still followed, with the optimization that the user does not need to type in the "user_code". The server SHOULD display the "user_code" to the user and ask them to verify that it matches the "user_code" being displayed on the device to confirm they are authorizing the correct device. As before, in addition to taking steps to confirm the identity of the device, the user should also be afforded the choice to approve or deny the authorization request.
如果用户通过导航到“verification_uri_complete”启动用户交互，则仍遵循第3.3节中描述的用户交互，并进行优化，用户无需键入“用户代码”。服务器应向用户显示“用户代码”，并要求他们验证其是否与设备上显示的“用户代码”匹配，以确认他们正在授权正确的设备。如前所述，除了采取步骤确认设备的身份外，还应向用户提供批准或拒绝授权请求的选择。
+-------------------------------------------------+
| |
| Scan the QR code or, using +------------+ |
| a browser on another device, |[_].. . [_]| |
| visit: | . .. . .| |
| https://example.com/device | . . . ....| |
| |. . . . | |
| And enter the code: |[_]. ... . | |
| WDJB-MJHT +------------+ |
| |
+-------------------------------------------------+
+-------------------------------------------------+
| |
| Scan the QR code or, using +------------+ |
| a browser on another device, |[_].. . [_]| |
| visit: | . .. . .| |
| https://example.com/device | . . . ....| |
| |. . . . | |
| And enter the code: |[_]. ... . | |
| WDJB-MJHT +------------+ |
| |
+-------------------------------------------------+
Figure 3: Example User Instruction with QR Code Representation of the Complete Verification URI
图3：带有完整验证URI的QR码表示的示例用户说明
After displaying instructions to the user, the client creates an access token request and sends it to the token endpoint (as defined by Section 3.2 of [RFC6749]) with a "grant_type" of "urn:ietf:params:oauth:grant-type:device_code". This is an extension grant type (as defined by Section 4.5 of [RFC6749]) created by this specification, with the following parameters:
在向用户显示指令后，客户端创建一个访问令牌请求，并将其发送到令牌端点（如[RFC6749]第3.2节所定义），其“授权类型”为“urn:ietf:params:oauth:grant type:device\u code”。这是由本规范创建的扩展授权类型（如[RFC6749]第4.5节所定义），具有以下参数：
grant_type REQUIRED. Value MUST be set to "urn:ietf:params:oauth:grant-type:device_code".
授权类型是必需的。值必须设置为“urn:ietf:params:oauth:grant type:device\u code”。
device_code REQUIRED. The device verification code, "device_code" from the device authorization response, defined in Section 3.2.
需要设备代码。第3.2节中定义的设备授权响应中的设备验证代码“设备代码”。
client_id REQUIRED if the client is not authenticating with the authorization server as described in Section 3.2.1. of [RFC6749]. The client identifier as described in Section 2.2 of [RFC6749].
如果客户端未按照第3.2.1节所述使用授权服务器进行身份验证，则需要客户端id。属于[RFC6749]。[RFC6749]第2.2节所述的客户标识符。
For example, the client makes the following HTTPS request (line breaks are for display purposes only):
例如，客户端发出以下HTTPS请求（换行符仅用于显示目的）：
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code &device_code=GmRhmhcxhwAzkoEqiMEg_DnyEysNkuNhszIySk9eS &client_id=1406020730
授权类型=urn%3 IETF%3参数%3 OAuth%3授权类型%3设备代码和设备代码=GmRhmhcxhwAzkoEqiMEg\u dnyeysnkunshiysk9es和客户端id=1406020730
If the client was issued client credentials (or assigned other authentication requirements), the client MUST authenticate with the authorization server as described in Section 3.2.1 of [RFC6749]. Note that there are security implications of statically distributed client credentials; see Section 5.6.
如果向客户端颁发了客户端凭据（或分配了其他身份验证要求），则客户端必须按照[RFC6749]第3.2.1节中的说明向授权服务器进行身份验证。请注意，静态分布的客户端凭据存在安全隐患；见第5.6节。
The response to this request is defined in Section 3.5. Unlike other OAuth grant types, it is expected for the client to try the access token request repeatedly in a polling fashion based on the error code in the response.
第3.5节规定了对该请求的响应。与其他OAuth授权类型不同，客户端应根据响应中的错误代码以轮询方式重复尝试访问令牌请求。
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].
如果用户已批准授权，令牌端点将以[RFC6749]第5.1节中定义的成功响应进行响应；否则，它会响应[RFC6749]第5.2节中定义的错误。
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:
除了[RFC6749]第5.2节中定义的错误代码外，还指定了以下错误代码，用于令牌端点响应中的设备授权授权：
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.
由于最终用户尚未完成用户交互步骤（第3.3节），授权请求仍处于挂起状态。客户端应向令牌端点重复访问令牌请求（称为轮询的过程）。在每个新请求之前，客户端必须至少等待设备授权响应的“interval”（间隔）参数指定的秒数（参见第3.2节），如果没有提供，则至少等待5秒，并考虑“slow_down”（减速）错误所要求的轮询间隔的任何增加。
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.
减慢“authorization_pending”的一种变体，授权请求仍处于挂起状态，轮询应继续，但此请求和所有后续请求的间隔必须增加5秒。
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.
过期的\u令牌“设备\u代码”已过期，设备授权会话已结束。客户端可以开始新的设备授权请求，但应等待用户交互后再重新启动，以避免不必要的轮询。
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.
“authorization_pending”和“slow_down”错误代码定义了特别独特的行为，因为它们表明OAuth客户端应该通过重复令牌请求（实现上面定义的精确行为）继续轮询令牌端点。如果客户端接收到带有任何其他错误代码的错误响应，它必须停止轮询，并应做出相应的反应，例如，向用户显示错误。
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.
本规范的假设是，用户在其上授权请求的单独设备没有与OAuth客户端通信回该设备的方式。此协议只需要一个单向通道，以最大限度地提高协议在受限环境中的生存能力，例如在仅能发出出站请求的电视上运行的应用程序。如果所选用户交互界面存在返回通道，则设备可以等待，直到该通道上通知用户已完成操作，然后再启动令牌请求（作为轮询的替代方案）。但是，此类行为不在本规范的范围内。
Support for this protocol is declared in OAuth 2.0 Authorization Server Metadata [RFC8414] as follows. The value "urn:ietf:params:oauth:grant-type:device_code" is included in values of the "grant_types_supported" key, and the following new key value pair is added:
OAuth 2.0授权服务器元数据[RFC8414]中声明了对该协议的支持，如下所示。值“urn:ietf:params:oauth:grant type:device\u code”包含在“grant\u types\u supported”密钥的值中，并添加以下新的密钥-值对：
device_authorization_endpoint OPTIONAL. URL of the authorization server's device authorization endpoint, as defined in Section 3.1.
设备\授权\端点可选。授权服务器的设备授权端点的URL，如第3.1节所定义。
Since the user code is typed by the user, shorter codes are more desirable for usability reasons. This means the entropy is typically less than would be used for the device code or other OAuth bearer token types where the code length does not impact usability. Therefore, it is recommended that the server rate-limit user code attempts.
由于用户代码是由用户键入的，因此出于可用性原因，更短的代码更可取。这意味着熵通常小于用于设备代码或其他OAuth承载令牌类型的熵，其中代码长度不影响可用性。因此，建议服务器速率限制用户代码尝试次数。
The user code SHOULD have enough entropy that, when combined with rate-limiting and other mitigations, a brute-force attack becomes infeasible. For example, it's generally held that 128-bit symmetric keys for encryption are seen as good enough today because an attacker has to put in 2^96 work to have a 2^-32 chance of guessing correctly via brute force. The rate-limiting and finite lifetime on the user code place an artificial limit on the amount of work an attacker can "do". If, for instance, one uses an 8-character base 20 user code (with roughly 34.5 bits of entropy), the rate-limiting interval and validity period would need to only allow 5 attempts in order to get the same 2^-32 probability of success by random guessing.
用户代码应该具有足够的熵，当与速率限制和其他缓解措施相结合时，暴力攻击变得不可行。例如，人们普遍认为128位对称加密密钥在今天看来已经足够好了，因为攻击者必须投入2^96的工作才能有2^-32的机会通过暴力正确猜测。用户代码的速率限制和有限生存期人为地限制了攻击者可以“做”的工作量。例如，如果使用8个字符的20进制用户代码（熵约为34.5位），则速率限制间隔和有效期只需允许5次尝试，即可通过随机猜测获得相同的2^-32成功概率。
A successful brute forcing of the user code would enable the attacker to approve the authorization grant with their own credentials, after which the device would receive a device authorization grant linked to the attacker's account. This is the opposite scenario to an OAuth bearer token being brute forced, whereby the attacker gains control of the victim's authorization grant. Such attacks may not always make economic sense. For example, for a video app, the device owner may then be able to purchase movies using the attacker's account (though even in this case a privacy risk would still remain and thus is important to protect against). Furthermore, some uses of the device flow give the granting account the ability to perform actions that need to be protected, such as controlling the device.
成功强制用户代码将使攻击者能够使用自己的凭据批准授权授予，之后设备将收到链接到攻击者帐户的设备授权授予。这与强制使用OAuth承载令牌的情况相反，攻击者借此获得对受害者授权的控制权。这种攻击可能并不总是有经济意义。例如，对于视频应用程序，设备所有者可能随后能够使用攻击者的帐户购买电影（尽管即使在这种情况下，隐私风险仍然存在，因此必须加以保护）。此外，设备流的某些使用使授权帐户能够执行需要保护的操作，例如控制设备。
The precise length of the user code and the entropy contained within is at the discretion of the authorization server, which needs to consider the sensitivity of their specific protected resources, the practicality of the code length from a usability standpoint, and any mitigations that are in place, such as rate-limiting, when determining the user code format.
用户代码的精确长度和包含在其中的熵取决于授权服务器，其需要考虑其特定保护资源的敏感性、代码长度的实用性和可用性的观点，以及诸如速率限制之类的任何缓解措施。确定用户代码格式时。
An attacker who guesses the device code would be able to potentially obtain the authorization code once the user completes the flow. As the device code is not displayed to the user and thus there are no usability considerations on the length, a very high entropy code SHOULD be used.
猜测设备代码的攻击者可以在用户完成流程后获得授权代码。由于设备代码未向用户显示，因此在长度上没有可用性考虑，因此应使用非常高的熵代码。
Unlike other native application OAuth 2.0 flows, the device requesting the authorization is not the same as the device from which the user grants access. Thus, signals from the approving user's session and device are not always relevant to the trustworthiness of the client device.
与其他本机应用程序OAuth 2.0流不同，请求授权的设备与用户授予访问权限的设备不同。因此，来自批准用户的会话和设备的信号并不总是与客户端设备的可信度相关。
Note that if an authorization server used with this flow is malicious, then it could perform a man-in-the-middle attack on the backchannel flow to another authorization server. In this scenario, the man-in-the-middle is not completely hidden from sight, as the end user would end up on the authorization page of the wrong service, giving them an opportunity to notice that the URL in the browser's address bar is wrong. For this to be possible, the device manufacturer must either be the attacker and shipping a device intended to perform the man-in-the-middle attack, or be using an authorization server that is controlled by an attacker, possibly because the attacker compromised the authorization server used by the device. In part, the person purchasing the device is counting on the manufacturer and its business partners to be trustworthy.
请注意，如果与此流一起使用的授权服务器是恶意的，那么它可能会对另一个授权服务器的反向通道流执行中间人攻击。在这种情况下，中间的人并不是完全看不见的，因为最终用户最终会出现在错误服务的授权页面上，让他们有机会注意到浏览器地址栏中的URL是错误的。要做到这一点，设备制造商必须是攻击者并运送一台旨在执行中间人攻击的设备，或者使用由攻击者控制的授权服务器，可能是因为攻击者破坏了设备使用的授权服务器。在某种程度上，购买设备的人指望制造商及其业务合作伙伴值得信赖。
It is possible for the device flow to be initiated on a device in an attacker's possession. For example, an attacker might send an email instructing the target user to visit the verification URL and enter the user code. To mitigate such an attack, it is RECOMMENDED to inform the user that they are authorizing a device during the user-interaction step (see Section 3.3) and to confirm that the device is in their possession. The authorization server SHOULD display information about the device so that the user could notice if a software client was attempting to impersonate a hardware device.
有可能在攻击者拥有的设备上启动设备流。例如，攻击者可能会发送电子邮件，指示目标用户访问验证URL并输入用户代码。为了减轻此类攻击，建议通知用户他们正在用户交互步骤（见第3.3节）期间授权设备，并确认设备在他们手中。授权服务器应显示有关设备的信息，以便用户能够注意到软件客户端是否试图模拟硬件设备。
For authorization servers that support the "verification_uri_complete" optimization discussed in Section 3.3.1, it is particularly important to confirm that the device is in the user's possession, as the user no longer has to type in the code being displayed on the device manually. One suggestion is to display the code during the authorization flow and ask the user to verify that the same code is currently being displayed on the device they are setting up.
对于支持第3.3.1节中讨论的“验证uri_完成”优化的授权服务器，确认设备为用户所有尤为重要，因为用户不再需要手动键入设备上显示的代码。一个建议是在授权流程中显示代码，并要求用户验证他们正在设置的设备上当前是否显示相同的代码。
The user code needs to have a long enough lifetime to be useable (allowing the user to retrieve their secondary device, navigate to the verification URI, log in, etc.) but should be sufficiently short to limit the usability of a code obtained for phishing. This doesn't prevent a phisher from presenting a fresh token, particularly if they are interacting with the user in real time, but it does limit the viability of codes sent over email or text message.
用户代码需要有足够长的生命周期才能使用（允许用户检索其辅助设备、导航到验证URI、登录等），但应足够短，以限制为钓鱼获取的代码的可用性。这并不能阻止网络钓鱼者提供新的令牌，特别是当他们与用户实时交互时，但它确实限制了通过电子邮件或短信发送代码的可行性。
While the device is pending authorization, it may be possible for a malicious user to physically spy on the device user interface (by viewing the screen on which it's displayed, for example) and hijack the session by completing the authorization faster than the user that initiated it. Devices SHOULD take into account the operating environment when considering how to communicate the code to the user to reduce the chances it will be observed by a malicious user.
当设备处于挂起授权状态时，恶意用户可能会对设备用户界面进行物理监视（例如，通过查看显示该界面的屏幕），并通过比发起授权的用户更快地完成授权来劫持会话。在考虑如何将代码传达给用户以减少恶意用户观察到代码的机会时，设备应考虑操作环境。
Device clients are generally incapable of maintaining the confidentiality of their credentials, as users in possession of the device can reverse-engineer it and extract the credentials. Therefore, unless additional measures are taken, they should be treated as public clients (as defined by Section 2.1 of [RFC6749]), which are susceptible to impersonation. The security considerations of Section 5.3.1 of [RFC6819] and Sections 8.5 and 8.6 of [RFC8252] apply to such clients.
设备客户端通常无法维护其凭据的机密性，因为拥有设备的用户可以对其进行反向工程并提取凭据。因此，除非采取额外措施，否则应将其视为公共客户（如[RFC6749]第2.1节所定义），其易被冒充。[RFC6819]第5.3.1节和[RFC8252]第8.5节和第8.6节的安全注意事项适用于此类客户。
The user may also be able to obtain the "device_code" and/or other OAuth bearer tokens issued to their client, which would allow them to use their own authorization grant directly by impersonating the client. Given that the user in possession of the client credentials can already impersonate the client and create a new authorization grant (with a new "device_code"), this doesn't represent a separate impersonation vector.
用户还可以获得发给其客户机的“设备代码”和/或其他OAuth承载令牌，这将允许他们通过模拟客户机直接使用自己的授权授权。假设拥有客户端凭据的用户已经可以模拟客户端并创建新的授权授予（使用新的“设备\代码”），这并不表示单独的模拟向量。
There is no requirement that the user code be displayed by the device visually. Other methods of one-way communication can potentially be used, such as text-to-speech audio or Bluetooth Low Energy. To mitigate an attack in which a malicious user can bootstrap their credentials on a device not in their control, it is RECOMMENDED that any chosen communication channel only be accessible by people in close proximity, for example, users who can see or hear the device.
不要求设备以视觉方式显示用户代码。可能会使用其他单向通信方法，例如文本到语音音频或蓝牙低能量。为了减轻恶意用户可以在不受其控制的设备上引导其凭据的攻击，建议任何选定的通信通道只能由近距离的人访问，例如，可以看到或听到设备的用户。
This section is a non-normative discussion of usability considerations.
本节是关于可用性注意事项的非规范性讨论。
For many users, their nearest Internet-connected device will be their mobile phone; typically, these devices offer input methods that are more time-consuming than a computer keyboard to change the case or input numbers. To improve usability (improving entry speed and reducing retries), the limitations of such devices should be taken into account when selecting the user code character set.
对于许多用户来说，离他们最近的互联网连接设备将是他们的手机；通常，这些设备提供的输入方法比计算机键盘更耗时，用于更改大小写或输入数字。为了提高可用性（提高输入速度和减少重试次数），在选择用户代码字符集时应考虑此类设备的限制。
One way to improve input speed is to restrict the character set to case-insensitive A-Z characters, with no digits. These characters can typically be entered on a mobile keyboard without using modifier keys. Further removing vowels to avoid randomly creating words results in the base 20 character set "BCDFGHJKLMNPQRSTVWXZ". Dashes or other punctuation may be included for readability.
提高输入速度的一种方法是将字符集限制为不区分大小写的A-Z字符，不带数字。这些字符通常可以在移动键盘上输入，而无需使用修改键。进一步删除元音以避免随机创建单词会导致基本的20个字符集“bcdfghjklmnpnpqrstvwxz”。为了便于阅读，可以包括破折号或其他标点符号。
An example user code following this guideline, "WDJB-MJHT", contains 8 significant characters and has dashes added for end-user readability. The resulting entropy is 20^8.
遵循本指南的示例用户代码“WDJB-MJHT”包含8个有效字符，并添加了破折号以提高最终用户的可读性。得到的熵是20^8。
Pure numeric codes are also a good choice for usability, especially for clients targeting locales where A-Z character keyboards are not used, though the length of such a code needs to be longer to maintain high entropy.
纯数字代码在可用性方面也是一个很好的选择，特别是针对不使用a-Z字符键盘的地区的客户机，尽管这样的代码的长度需要更长才能保持高熵。
An example numeric user code that contains 9 significant digits and dashes added for end-user readability with an entropy of 10^9 is "019-450-730".
“019-450-730”是一个示例数字用户代码，其中包含9个有效数字和为最终用户可读性添加的破折号，熵为10^9。
When processing the inputted user code, the server should strip dashes and other punctuation that it added for readability (making the inclusion of such punctuation by the user optional). For codes using only characters in the A-Z range, as with the base 20 charset defined above, the user's input should be uppercased before a comparison to account for the fact that the user may input the equivalent lowercase characters. Further stripping of all characters outside the chosen character set is recommended to reduce instances where an errantly typed character (like a space character) invalidates otherwise valid input.
在处理输入的用户代码时，服务器应去除其添加的破折号和其他标点符号以确保可读性（用户可选择包含此类标点符号）。对于仅使用A-Z范围内的字符的代码，与上面定义的基20字符集一样，在进行比较之前，用户的输入应该是大写的，以说明用户可以输入等效的小写字符。建议进一步剥离所选字符集之外的所有字符，以减少错误键入的字符（如空格字符）使其他有效输入无效的情况。
It is RECOMMENDED to avoid character sets that contain two or more characters that can easily be confused with each other, like "0" and "O" or "1", "l" and "I". Furthermore, to the extent practical, when a character set contains a character that may be confused with characters outside the character set, a character outside the set MAY be substituted with the one in the character set with which it is commonly confused; for example, "O" may be substituted for "0" when using the numerical 0-9 character set.
建议避免包含两个或更多容易相互混淆的字符集，如“0”和“O”或“1”、“l”和“I”。此外，在实际范围内，当字符集包含可能与字符集外的字符混淆的字符时，可将该字符集外的字符替换为通常与之混淆的字符集中的字符；例如，当使用数字0-9字符集时，“O”可以替换为“0”。
Devices and authorization servers MAY negotiate an alternative code transmission and user-interaction method in addition to the one described in Section 3.3. Such an alternative user-interaction flow could obviate the need for a browser and manual input of the code, for example, by using Bluetooth to transmit the code to the authorization server's companion app. Such interaction methods can utilize this protocol as, ultimately, the user just needs to identify the authorization session to the authorization server; however, user interaction other than through the verification URI is outside the scope of this specification.
除第3.3节所述方法外，设备和授权服务器还可以协商其他代码传输和用户交互方法。例如，通过使用蓝牙将代码传输到授权服务器的配套应用程序，这种替代用户交互流可以消除浏览器和手动输入代码的需要。这种交互方法可以利用该协议，因为最终用户只需要识别到授权服务器的授权会话；但是，通过验证URI以外的用户交互不在本规范的范围内。
This specification registers the following values in the IANA "OAuth Parameters" registry [IANA.OAuth.Parameters] established by [RFC6749].
本规范在[RFC6749]建立的IANA“OAuth参数”注册表[IANA.OAuth.Parameters]中注册以下值。
Name: device_code Parameter Usage Location: token request Change Controller: IESG Reference: Section 3.4 of RFC 8628
名称：设备代码参数使用位置：令牌请求更改控制器：IESG参考：RFC 8628第3.4节
This specification registers the following values in the IANA "OAuth URI" registry [IANA.OAuth.Parameters] established by [RFC6755].
本规范在[RFC6755]建立的IANA“OAuth URI”注册表[IANA.OAuth.Parameters]中注册以下值。
URN: urn:ietf:params:oauth:grant-type:device_code
Common Name: Device Authorization Grant Type for OAuth 2.0
Change Controller: IESG
Specification Document: Section 3.4 of RFC 8628
URN: urn:ietf:params:oauth:grant-type:device_code
Common Name: Device Authorization Grant Type for OAuth 2.0
Change Controller: IESG
Specification Document: Section 3.4 of RFC 8628
This specification registers the following values in the IANA "OAuth Extensions Error Registry" registry [IANA.OAuth.Parameters] established by [RFC6749].
本规范在[RFC6749]建立的IANA“OAuth扩展错误注册表”注册表[IANA.OAuth.Parameters]中注册以下值。
Name: authorization_pending Usage Location: Token endpoint response Protocol Extension: RFC 8628 Change Controller: IETF Reference: Section 3.5 of RFC 8628
名称：授权\u待定使用位置：令牌端点响应协议扩展：RFC 8628变更控制器：IETF参考：RFC 8628第3.5节
Name: access_denied Usage Location: Token endpoint response Protocol Extension: RFC 8628 Change Controller: IETF Reference: Section 3.5 of RFC 8628
名称：访问被拒绝使用位置：令牌端点响应协议扩展：RFC 8628更改控制器：IETF参考：RFC 8628第3.5节
Name: slow_down Usage Location: Token endpoint response Protocol Extension: RFC 8628 Change Controller: IETF Reference: Section 3.5 of RFC 8628
名称：减速使用位置：令牌端点响应协议扩展：RFC 8628更改控制器：IETF参考：RFC 8628第3.5节
Name: expired_token Usage Location: Token endpoint response Protocol Extension: RFC 8628 Change Controller: IETF Reference: Section 3.5 of RFC 8628
名称：过期的\u令牌使用位置：令牌端点响应协议扩展：RFC 8628更改控制器：IETF参考：RFC 8628第3.5节
This specification registers the following values in the IANA "OAuth Authorization Server Metadata" registry [IANA.OAuth.Parameters] established by [RFC8414].
本规范在[RFC8414]建立的IANA“OAuth授权服务器元数据”注册表[IANA.OAuth.Parameters]中注册以下值。
Metadata name: device_authorization_endpoint Metadata Description: URL of the authorization server's device authorization endpoint Change Controller: IESG Reference: Section 4 of RFC 8628
元数据名称：设备\授权\端点元数据描述：授权服务器的设备授权端点更改控制器的URL:IESG参考：RFC 8628第4节
[IANA.OAuth.Parameters] IANA, "OAuth Parameters", <http://www.iana.org/assignments/oauth-parameters>.
[IANA.OAuth.Parameters]IANA，“OAuth参数”<http://www.iana.org/assignments/oauth-parameters>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/info/rfc6749>.
[RFC6749]Hardt，D.，Ed.“OAuth 2.0授权框架”，RFC 6749，DOI 10.17487/RFC6749，2012年10月<https://www.rfc-editor.org/info/rfc6749>.
[RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace for OAuth", RFC 6755, DOI 10.17487/RFC6755, October 2012, <https://www.rfc-editor.org/info/rfc6755>.
[RFC6755]Campbell，B.和H.Tschofenig，“OAuth的IETF URN子名称空间”，RFC 6755，DOI 10.17487/RFC6755，2012年10月<https://www.rfc-editor.org/info/rfc6755>.
[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 Threat Model and Security Considerations", RFC 6819, DOI 10.17487/RFC6819, January 2013, <https://www.rfc-editor.org/info/rfc6819>.
[RFC6819]Lodderstet，T.，Ed.，McGloin，M.，和P.Hunt，“OAuth 2.0威胁模型和安全考虑”，RFC 6819，DOI 10.17487/RFC6819，2013年1月<https://www.rfc-editor.org/info/rfc6819>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<https://www.rfc-editor.org/info/rfc7525>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8252] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps", BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017, <https://www.rfc-editor.org/info/rfc8252>.
[RFC8252]Denniss，W.和J.Bradley，“本地应用的OAuth 2.0”，BCP 212，RFC 8252，DOI 10.17487/RFC8252，2017年10月<https://www.rfc-editor.org/info/rfc8252>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259]Bray，T.，Ed.“JavaScript对象表示法（JSON）数据交换格式”，STD 90，RFC 8259，DOI 10.17487/RFC8259，2017年12月<https://www.rfc-editor.org/info/rfc8259>.
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, <https://www.rfc-editor.org/info/rfc8414>.
[RFC8414]Jones，M.，Sakimura，N.，和J.Bradley，“OAuth 2.0授权服务器元数据”，RFC 8414，DOI 10.17487/RFC8414，2018年6月<https://www.rfc-editor.org/info/rfc8414>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446]Rescorla，E.“传输层安全（TLS）协议版本1.3”，RFC 8446，DOI 10.17487/RFC8446，2018年8月<https://www.rfc-editor.org/info/rfc8446>.
Acknowledgements
致谢
The starting point for this document was the Internet-Draft draft-recordon-oauth-v2-device, authored by David Recordon and Brent Goldman, which itself was based on content in draft versions of the OAuth 2.0 protocol specification removed prior to publication due to a then-lack of sufficient deployment expertise. Thank you to the OAuth Working Group members who contributed to those earlier drafts.
本文档的起点是互联网草稿Draft-recordon-oauth-v2-device，由David recordon和Brent Goldman编写，其本身基于oauth 2.0协议规范草案版本中的内容，该规范在发布之前已删除，因为当时缺乏足够的部署专业知识。感谢非统组织工作组成员对这些早期草案作出贡献。
This document was produced in the OAuth Working Group under the chairpersonship of Rifaat Shekh-Yusef and Hannes Tschofenig, with Benjamin Kaduk, Kathleen Moriarty, and Eric Rescorla serving as Security Area Directors.
本文件由Rifaat Shekh Yusef和Hannes Tschofenig担任主席，由Benjamin Kaduk、Kathleen Moriarty和Eric Rescorla担任安全区域主任，由OAuth工作组编制。
The following individuals contributed ideas, feedback, and wording that shaped and formed the final specification:
以下人员提供了形成最终规范的想法、反馈和措辞：
Ben Campbell, Brian Campbell, Roshni Chandrashekhar, Alissa Cooper, Eric Fazendin, Benjamin Kaduk, Jamshid Khosravian, Mirja Kuehlewind, Torsten Lodderstedt, James Manger, Dan McNulty, Breno de Medeiros, Alexey Melnikov, Simon Moffatt, Stein Myrseth, Emond Papegaaij, Justin Richer, Adam Roach, Nat Sakimura, Andrew Sciberras, Marius Scurtescu, Filip Skokan, Robert Sparks, Ken Wang, Christopher Wood, Steven E. Wright, and Qin Wu.
本·坎贝尔、布赖恩·坎贝尔、罗什尼·钱德拉舍哈尔、艾莉莎·库珀、埃里克·法泽丁、本杰明·卡杜克、贾姆希德·科斯拉维、米迦·库勒温德、托斯滕·洛德斯特德、詹姆斯·马格尔、丹·麦克纳尔蒂、布伦诺·德梅德罗斯、阿列克谢·梅尔尼科夫、西蒙·莫法特、斯坦·迈尔塞思、埃蒙·帕佩加伊、贾斯汀·里希、亚当·罗奇、纳特·萨基村、安德鲁·西贝拉斯、马吕斯·斯库特斯库、，菲利普·斯科坎、罗伯特·斯帕克斯、肯·王、克里斯托弗·伍德、史蒂文·E·赖特和秦武。
Authors' Addresses
作者地址
William Denniss Google 1600 Amphitheatre Pkwy Mountain View, CA 94043 United States of America
威廉·丹尼斯谷歌1600圆形剧场美国加利福尼亚州山景城Pkwy，邮编94043
Email: wdenniss@google.com
URI: https://wdenniss.com/deviceflow
Email: wdenniss@google.com
URI: https://wdenniss.com/deviceflow
John Bradley Ping Identity
约翰·布拉德利·平身份
Email: ve7jtb@ve7jtb.com
URI: http://www.thread-safe.com/
Email: ve7jtb@ve7jtb.com
URI: http://www.thread-safe.com/
Michael B. Jones Microsoft
迈克尔·琼斯微软公司
Email: mbj@microsoft.com
URI: http://self-issued.info/
Email: mbj@microsoft.com
URI: http://self-issued.info/
Hannes Tschofenig ARM Limited Austria
Hannes Tschofenig ARM Limited奥地利
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at