Internet Engineering Task Force (IETF) D. Hardt, Ed.
Request for Comments: 6749 Microsoft
Obsoletes: 5849 October 2012
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) D. Hardt, Ed.
Request for Comments: 6749 Microsoft
Obsoletes: 5849 October 2012
Category: Standards Track
ISSN: 2070-1721
The OAuth 2.0 Authorization Framework
OAuth2.0授权框架
Abstract
摘要
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849.
OAuth 2.0授权框架使第三方应用程序能够代表资源所有者获得对HTTP服务的有限访问权，方法是协调资源所有者和HTTP服务之间的批准交互，或者允许第三方应用程序代表自己获得访问权。本规范取代并废除RFC 5849中描述的OAuth 1.0协议。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6749.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6749.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Roles ......................................................6
1.2. Protocol Flow ..............................................7
1.3. Authorization Grant ........................................8
1.3.1. Authorization Code ..................................8
1.3.2. Implicit ............................................8
1.3.3. Resource Owner Password Credentials .................9
1.3.4. Client Credentials ..................................9
1.4. Access Token ..............................................10
1.5. Refresh Token .............................................10
1.6. TLS Version ...............................................12
1.7. HTTP Redirections .........................................12
1.8. Interoperability ..........................................12
1.9. Notational Conventions ....................................13
2. Client Registration ............................................13
2.1. Client Types ..............................................14
2.2. Client Identifier .........................................15
2.3. Client Authentication .....................................16
2.3.1. Client Password ....................................16
2.3.2. Other Authentication Methods .......................17
2.4. Unregistered Clients ......................................17
3. Protocol Endpoints .............................................18
3.1. Authorization Endpoint ....................................18
3.1.1. Response Type ......................................19
3.1.2. Redirection Endpoint ...............................19
3.2. Token Endpoint ............................................21
3.2.1. Client Authentication ..............................22
3.3. Access Token Scope ........................................23
4. Obtaining Authorization ........................................23
4.1. Authorization Code Grant ..................................24
4.1.1. Authorization Request ..............................25
4.1.2. Authorization Response .............................26
4.1.3. Access Token Request ...............................29
4.1.4. Access Token Response ..............................30
4.2. Implicit Grant ............................................31
4.2.1. Authorization Request ..............................33
4.2.2. Access Token Response ..............................35
4.3. Resource Owner Password Credentials Grant .................37
4.3.1. Authorization Request and Response .................39
4.3.2. Access Token Request ...............................39
4.3.3. Access Token Response ..............................40
4.4. Client Credentials Grant ..................................40
4.4.1. Authorization Request and Response .................41
4.4.2. Access Token Request ...............................41
4.4.3. Access Token Response ..............................42
4.5. Extension Grants ..........................................42
1. Introduction ....................................................4
1.1. Roles ......................................................6
1.2. Protocol Flow ..............................................7
1.3. Authorization Grant ........................................8
1.3.1. Authorization Code ..................................8
1.3.2. Implicit ............................................8
1.3.3. Resource Owner Password Credentials .................9
1.3.4. Client Credentials ..................................9
1.4. Access Token ..............................................10
1.5. Refresh Token .............................................10
1.6. TLS Version ...............................................12
1.7. HTTP Redirections .........................................12
1.8. Interoperability ..........................................12
1.9. Notational Conventions ....................................13
2. Client Registration ............................................13
2.1. Client Types ..............................................14
2.2. Client Identifier .........................................15
2.3. Client Authentication .....................................16
2.3.1. Client Password ....................................16
2.3.2. Other Authentication Methods .......................17
2.4. Unregistered Clients ......................................17
3. Protocol Endpoints .............................................18
3.1. Authorization Endpoint ....................................18
3.1.1. Response Type ......................................19
3.1.2. Redirection Endpoint ...............................19
3.2. Token Endpoint ............................................21
3.2.1. Client Authentication ..............................22
3.3. Access Token Scope ........................................23
4. Obtaining Authorization ........................................23
4.1. Authorization Code Grant ..................................24
4.1.1. Authorization Request ..............................25
4.1.2. Authorization Response .............................26
4.1.3. Access Token Request ...............................29
4.1.4. Access Token Response ..............................30
4.2. Implicit Grant ............................................31
4.2.1. Authorization Request ..............................33
4.2.2. Access Token Response ..............................35
4.3. Resource Owner Password Credentials Grant .................37
4.3.1. Authorization Request and Response .................39
4.3.2. Access Token Request ...............................39
4.3.3. Access Token Response ..............................40
4.4. Client Credentials Grant ..................................40
4.4.1. Authorization Request and Response .................41
4.4.2. Access Token Request ...............................41
4.4.3. Access Token Response ..............................42
4.5. Extension Grants ..........................................42
5. Issuing an Access Token ........................................43
5.1. Successful Response .......................................43
5.2. Error Response ............................................45
6. Refreshing an Access Token .....................................47
7. Accessing Protected Resources ..................................48
7.1. Access Token Types ........................................49
7.2. Error Response ............................................49
8. Extensibility ..................................................50
8.1. Defining Access Token Types ...............................50
8.2. Defining New Endpoint Parameters ..........................50
8.3. Defining New Authorization Grant Types ....................51
8.4. Defining New Authorization Endpoint Response Types ........51
8.5. Defining Additional Error Codes ...........................51
9. Native Applications ............................................52
10. Security Considerations .......................................53
10.1. Client Authentication ....................................53
10.2. Client Impersonation .....................................54
10.3. Access Tokens ............................................55
10.4. Refresh Tokens ...........................................55
10.5. Authorization Codes ......................................56
10.6. Authorization Code Redirection URI Manipulation ..........56
10.7. Resource Owner Password Credentials ......................57
10.8. Request Confidentiality ..................................58
10.9. Ensuring Endpoint Authenticity ...........................58
10.10. Credentials-Guessing Attacks ............................58
10.11. Phishing Attacks ........................................58
10.12. Cross-Site Request Forgery ..............................59
10.13. Clickjacking ............................................60
10.14. Code Injection and Input Validation .....................60
10.15. Open Redirectors ........................................60
10.16. Misuse of Access Token to Impersonate Resource
Owner in Implicit Flow ..................................61
11. IANA Considerations ...........................................62
11.1. OAuth Access Token Types Registry ........................62
11.1.1. Registration Template .............................62
11.2. OAuth Parameters Registry ................................63
11.2.1. Registration Template .............................63
11.2.2. Initial Registry Contents .........................64
11.3. OAuth Authorization Endpoint Response Types Registry .....66
11.3.1. Registration Template .............................66
11.3.2. Initial Registry Contents .........................67
11.4. OAuth Extensions Error Registry ..........................67
11.4.1. Registration Template .............................68
12. References ....................................................68
12.1. Normative References .....................................68
12.2. Informative References ...................................70
5. Issuing an Access Token ........................................43
5.1. Successful Response .......................................43
5.2. Error Response ............................................45
6. Refreshing an Access Token .....................................47
7. Accessing Protected Resources ..................................48
7.1. Access Token Types ........................................49
7.2. Error Response ............................................49
8. Extensibility ..................................................50
8.1. Defining Access Token Types ...............................50
8.2. Defining New Endpoint Parameters ..........................50
8.3. Defining New Authorization Grant Types ....................51
8.4. Defining New Authorization Endpoint Response Types ........51
8.5. Defining Additional Error Codes ...........................51
9. Native Applications ............................................52
10. Security Considerations .......................................53
10.1. Client Authentication ....................................53
10.2. Client Impersonation .....................................54
10.3. Access Tokens ............................................55
10.4. Refresh Tokens ...........................................55
10.5. Authorization Codes ......................................56
10.6. Authorization Code Redirection URI Manipulation ..........56
10.7. Resource Owner Password Credentials ......................57
10.8. Request Confidentiality ..................................58
10.9. Ensuring Endpoint Authenticity ...........................58
10.10. Credentials-Guessing Attacks ............................58
10.11. Phishing Attacks ........................................58
10.12. Cross-Site Request Forgery ..............................59
10.13. Clickjacking ............................................60
10.14. Code Injection and Input Validation .....................60
10.15. Open Redirectors ........................................60
10.16. Misuse of Access Token to Impersonate Resource
Owner in Implicit Flow ..................................61
11. IANA Considerations ...........................................62
11.1. OAuth Access Token Types Registry ........................62
11.1.1. Registration Template .............................62
11.2. OAuth Parameters Registry ................................63
11.2.1. Registration Template .............................63
11.2.2. Initial Registry Contents .........................64
11.3. OAuth Authorization Endpoint Response Types Registry .....66
11.3.1. Registration Template .............................66
11.3.2. Initial Registry Contents .........................67
11.4. OAuth Extensions Error Registry ..........................67
11.4.1. Registration Template .............................68
12. References ....................................................68
12.1. Normative References .....................................68
12.2. Informative References ...................................70
Appendix A. Augmented Backus-Naur Form (ABNF) Syntax ..............71
A.1. "client_id" Syntax ........................................71
A.2. "client_secret" Syntax ....................................71
A.3. "response_type" Syntax ....................................71
A.4. "scope" Syntax ............................................72
A.5. "state" Syntax ............................................72
A.6. "redirect_uri" Syntax .....................................72
A.7. "error" Syntax ............................................72
A.8. "error_description" Syntax ................................72
A.9. "error_uri" Syntax ........................................72
A.10. "grant_type" Syntax .......................................73
A.11. "code" Syntax .............................................73
A.12. "access_token" Syntax .....................................73
A.13. "token_type" Syntax .......................................73
A.14. "expires_in" Syntax .......................................73
A.15. "username" Syntax .........................................73
A.16. "password" Syntax .........................................73
A.17. "refresh_token" Syntax ....................................74
A.18. Endpoint Parameter Syntax .................................74
Appendix B. Use of application/x-www-form-urlencoded Media Type ...74
Appendix C. Acknowledgements ......................................75
Appendix A. Augmented Backus-Naur Form (ABNF) Syntax ..............71
A.1. "client_id" Syntax ........................................71
A.2. "client_secret" Syntax ....................................71
A.3. "response_type" Syntax ....................................71
A.4. "scope" Syntax ............................................72
A.5. "state" Syntax ............................................72
A.6. "redirect_uri" Syntax .....................................72
A.7. "error" Syntax ............................................72
A.8. "error_description" Syntax ................................72
A.9. "error_uri" Syntax ........................................72
A.10. "grant_type" Syntax .......................................73
A.11. "code" Syntax .............................................73
A.12. "access_token" Syntax .....................................73
A.13. "token_type" Syntax .......................................73
A.14. "expires_in" Syntax .......................................73
A.15. "username" Syntax .........................................73
A.16. "password" Syntax .........................................73
A.17. "refresh_token" Syntax ....................................74
A.18. Endpoint Parameter Syntax .................................74
Appendix B. Use of application/x-www-form-urlencoded Media Type ...74
Appendix C. Acknowledgements ......................................75
In the traditional client-server authentication model, the client requests an access-restricted resource (protected resource) on the server by authenticating with the server using the resource owner's credentials. In order to provide third-party applications access to restricted resources, the resource owner shares its credentials with the third party. This creates several problems and limitations:
在传统的客户机-服务器身份验证模型中，客户机通过使用资源所有者的凭据与服务器进行身份验证来请求服务器上的访问受限资源（受保护的资源）。为了向第三方应用程序提供对受限资源的访问，资源所有者与第三方共享其凭据。这造成了一些问题和限制：
o Third-party applications are required to store the resource owner's credentials for future use, typically a password in clear-text.
o 第三方应用程序需要存储资源所有者的凭据以供将来使用，通常是明文密码。
o Servers are required to support password authentication, despite the security weaknesses inherent in passwords.
o 服务器需要支持密码身份验证，尽管密码本身存在安全缺陷。
o Third-party applications gain overly broad access to the resource owner's protected resources, leaving resource owners without any ability to restrict duration or access to a limited subset of resources.
o 第三方应用程序获得了对资源所有者的受保护资源的过于广泛的访问，使得资源所有者无法限制持续时间或对有限资源子集的访问。
o Resource owners cannot revoke access to an individual third party without revoking access to all third parties, and must do so by changing the third party's password.
o 资源所有者不能在不撤销对所有第三方的访问的情况下撤销对单个第三方的访问，并且必须通过更改第三方的密码来做到这一点。
o Compromise of any third-party application results in compromise of the end-user's password and all of the data protected by that password.
o 任何第三方应用程序的泄露都会导致最终用户的密码以及受该密码保护的所有数据的泄露。
OAuth addresses these issues by introducing an authorization layer and separating the role of the client from that of the resource owner. In OAuth, the client requests access to resources controlled by the resource owner and hosted by the resource server, and is issued a different set of credentials than those of the resource owner.
OAuth通过引入授权层并将客户机的角色与资源所有者的角色分离来解决这些问题。在OAuth中，客户机请求访问由资源所有者控制、由资源服务器托管的资源，并获得与资源所有者不同的一组凭据。
Instead of using the resource owner's credentials to access protected resources, the client obtains an access token -- a string denoting a specific scope, lifetime, and other access attributes. Access tokens are issued to third-party clients by an authorization server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource server.
客户端不使用资源所有者的凭据访问受保护的资源，而是获取一个访问令牌——一个表示特定范围、生存期和其他访问属性的字符串。经资源所有者批准，授权服务器将访问令牌颁发给第三方客户端。客户端使用访问令牌访问由资源服务器承载的受保护资源。
For example, an end-user (resource owner) can grant a printing service (client) access to her protected photos stored at a photo-sharing service (resource server), without sharing her username and password with the printing service. Instead, she authenticates directly with a server trusted by the photo-sharing service (authorization server), which issues the printing service delegation-specific credentials (access token).
例如，最终用户（资源所有者）可以授予打印服务（客户端）访问存储在照片共享服务（资源服务器）中的受保护照片的权限，而无需与打印服务共享其用户名和密码。相反，她直接使用照片共享服务（授权服务器）信任的服务器进行身份验证，该服务器将颁发打印服务特定于授权的凭据（访问令牌）。
This specification is designed for use with HTTP ([RFC2616]). The use of OAuth over any protocol other than HTTP is out of scope.
本规范设计用于HTTP（[RFC2616]）。在HTTP以外的任何协议上使用OAuth超出了范围。
The OAuth 1.0 protocol ([RFC5849]), published as an informational document, was the result of a small ad hoc community effort. This Standards Track specification builds on the OAuth 1.0 deployment experience, as well as additional use cases and extensibility requirements gathered from the wider IETF community. The OAuth 2.0 protocol is not backward compatible with OAuth 1.0. The two versions may co-exist on the network, and implementations may choose to support both. However, it is the intention of this specification that new implementations support OAuth 2.0 as specified in this document and that OAuth 1.0 is used only to support existing deployments. The OAuth 2.0 protocol shares very few implementation details with the OAuth 1.0 protocol. Implementers familiar with OAuth 1.0 should approach this document without any assumptions as to its structure and details.
OAuth 1.0协议（[RFC5849]）作为一个信息性文档发布，是一个小型特别社区努力的结果。本标准跟踪规范建立在OAuth 1.0部署经验以及从更广泛的IETF社区收集的其他用例和扩展性需求的基础上。OAuth 2.0协议与OAuth 1.0不向后兼容。这两个版本可能在网络上共存，实现可能会选择同时支持这两个版本。但是，本规范的目的是，新的实现支持本文档中指定的OAuth 2.0，并且OAuth 1.0仅用于支持现有部署。OAuth 2.0协议与OAuth 1.0协议共享很少的实现细节。熟悉OAuth 1.0的实现者应在不考虑其结构和细节的情况下访问本文档。
OAuth defines four roles:
OAuth定义了四个角色：
resource owner An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user.
资源所有者能够授予对受保护资源的访问权限的实体。当资源所有者是个人时，它被称为最终用户。
resource server The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.
资源服务器托管受保护资源的服务器，能够使用访问令牌接受和响应受保护资源请求。
client An application making protected resource requests on behalf of the resource owner and with its authorization. The term "client" does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices).
客户机代表资源所有者及其授权发出受保护资源请求的应用程序。术语“客户端”并不意味着任何特定的实现特征（例如，应用程序是否在服务器、桌面或其他设备上执行）。
authorization server The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.
授权服务器成功验证资源所有者并获得授权后向客户端颁发访问令牌的服务器。
The interaction between the authorization server and resource server is beyond the scope of this specification. The authorization server may be the same server as the resource server or a separate entity. A single authorization server may issue access tokens accepted by multiple resource servers.
授权服务器和资源服务器之间的交互超出了本规范的范围。授权服务器可以是与资源服务器相同的服务器，也可以是单独的实体。单个授权服务器可以发出多个资源服务器接受的访问令牌。
+--------+ +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+
+--------+ +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+
Figure 1: Abstract Protocol Flow
图1：抽象协议流
The abstract OAuth 2.0 flow illustrated in Figure 1 describes the interaction between the four roles and includes the following steps:
图1所示的抽象OAuth 2.0流程描述了四个角色之间的交互，包括以下步骤：
(A) The client requests authorization from the resource owner. The authorization request can be made directly to the resource owner (as shown), or preferably indirectly via the authorization server as an intermediary.
（A） 客户端向资源所有者请求授权。授权请求可以直接向资源所有者发出（如图所示），或者优选地通过作为中介的授权服务器间接发出。
(B) The client receives an authorization grant, which is a credential representing the resource owner's authorization, expressed using one of four grant types defined in this specification or using an extension grant type. The authorization grant type depends on the method used by the client to request authorization and the types supported by the authorization server.
（B） 客户端接收授权授予，这是表示资源所有者授权的凭证，使用本规范中定义的四种授予类型之一或扩展授予类型表示。授权授予类型取决于客户端用于请求授权的方法以及授权服务器支持的类型。
(C) The client requests an access token by authenticating with the authorization server and presenting the authorization grant.
（C） 客户端通过与授权服务器进行身份验证并提供授权授予来请求访问令牌。
(D) The authorization server authenticates the client and validates the authorization grant, and if valid, issues an access token.
（D） 授权服务器对客户端进行身份验证并验证授权授予，如果有效，则发出访问令牌。
(E) The client requests the protected resource from the resource server and authenticates by presenting the access token.
（E） 客户端从资源服务器请求受保护的资源，并通过提供访问令牌进行身份验证。
(F) The resource server validates the access token, and if valid, serves the request.
（F） 资源服务器验证访问令牌，如果有效，则为请求提供服务。
The preferred method for the client to obtain an authorization grant from the resource owner (depicted in steps (A) and (B)) is to use the authorization server as an intermediary, which is illustrated in Figure 3 in Section 4.1.
客户端从资源所有者处获得授权授予的首选方法（在步骤（A）和（B）中描述）是使用授权服务器作为中介，如第4.1节中的图3所示。
An authorization grant is a credential representing the resource owner's authorization (to access its protected resources) used by the client to obtain an access token. This specification defines four grant types -- authorization code, implicit, resource owner password credentials, and client credentials -- as well as an extensibility mechanism for defining additional types.
授权授权是一种凭证，表示客户端用于获取访问令牌的资源所有者授权（访问其受保护资源）。该规范定义了四种授权类型——授权代码、隐式、资源所有者密码凭据和客户端凭据——以及用于定义其他类型的扩展机制。
The authorization code is obtained by using an authorization server as an intermediary between the client and resource owner. Instead of requesting authorization directly from the resource owner, the client directs the resource owner to an authorization server (via its user-agent as defined in [RFC2616]), which in turn directs the resource owner back to the client with the authorization code.
授权代码是通过使用授权服务器作为客户端和资源所有者之间的中介来获得的。客户端不直接从资源所有者请求授权，而是将资源所有者定向到授权服务器（通过[RFC2616]中定义的用户代理），授权服务器反过来将资源所有者定向回具有授权代码的客户端。
Before directing the resource owner back to the client with the authorization code, the authorization server authenticates the resource owner and obtains authorization. Because the resource owner only authenticates with the authorization server, the resource owner's credentials are never shared with the client.
在使用授权代码将资源所有者定向回客户机之前，授权服务器将对资源所有者进行身份验证并获得授权。由于资源所有者仅与授权服务器进行身份验证，因此资源所有者的凭据永远不会与客户端共享。
The authorization code provides a few important security benefits, such as the ability to authenticate the client, as well as the transmission of the access token directly to the client without passing it through the resource owner's user-agent and potentially exposing it to others, including the resource owner.
授权代码提供了一些重要的安全优势，例如验证客户端的能力，以及直接将访问令牌传输到客户端，而无需将其通过资源所有者的用户代理，并可能将其暴露给其他人，包括资源所有者。
The implicit grant is a simplified authorization code flow optimized for clients implemented in a browser using a scripting language such as JavaScript. In the implicit flow, instead of issuing the client an authorization code, the client is issued an access token directly
隐式授权是一种简化的授权代码流，针对使用JavaScript等脚本语言在浏览器中实现的客户端进行了优化。在隐式流中，不向客户端发出授权码，而是直接向客户端发出访问令牌
(as the result of the resource owner authorization). The grant type is implicit, as no intermediate credentials (such as an authorization code) are issued (and later used to obtain an access token).
（作为资源所有者授权的结果）。授予类型是隐式的，因为没有颁发中间凭证（如授权码）（随后用于获取访问令牌）。
When issuing an access token during the implicit grant flow, the authorization server does not authenticate the client. In some cases, the client identity can be verified via the redirection URI used to deliver the access token to the client. The access token may be exposed to the resource owner or other applications with access to the resource owner's user-agent.
在隐式授权流期间发出访问令牌时，授权服务器不会对客户端进行身份验证。在某些情况下，可以通过用于将访问令牌传递给客户端的重定向URI来验证客户端身份。访问令牌可以公开给资源所有者或具有对资源所有者的用户代理的访问权限的其他应用程序。
Implicit grants improve the responsiveness and efficiency of some clients (such as a client implemented as an in-browser application), since it reduces the number of round trips required to obtain an access token. However, this convenience should be weighed against the security implications of using implicit grants, such as those described in Sections 10.3 and 10.16, especially when the authorization code grant type is available.
隐式授权提高了某些客户端（例如作为浏览器内应用程序实现的客户端）的响应能力和效率，因为它减少了获取访问令牌所需的往返次数。然而，这种便利性应与使用隐式授权（如第10.3节和第10.16节所述）的安全影响进行权衡，特别是当授权码授权类型可用时。
The resource owner password credentials (i.e., username and password) can be used directly as an authorization grant to obtain an access token. The credentials should only be used when there is a high degree of trust between the resource owner and the client (e.g., the client is part of the device operating system or a highly privileged application), and when other authorization grant types are not available (such as an authorization code).
资源所有者密码凭据（即用户名和密码）可以直接用作授权，以获得访问令牌。仅当资源所有者和客户端之间存在高度信任时（例如，客户端是设备操作系统或高度特权应用程序的一部分），以及当其他授权授予类型不可用时（例如授权代码），才应使用凭据。
Even though this grant type requires direct client access to the resource owner credentials, the resource owner credentials are used for a single request and are exchanged for an access token. This grant type can eliminate the need for the client to store the resource owner credentials for future use, by exchanging the credentials with a long-lived access token or refresh token.
即使此授予类型要求客户端直接访问资源所有者凭据，资源所有者凭据也用于单个请求，并交换为访问令牌。通过与长期访问令牌或刷新令牌交换凭据，此授予类型可以消除客户端存储资源所有者凭据以供将来使用的需要。
The client credentials (or other forms of client authentication) can be used as an authorization grant when the authorization scope is limited to the protected resources under the control of the client, or to protected resources previously arranged with the authorization server. Client credentials are used as an authorization grant typically when the client is acting on its own behalf (the client is also the resource owner) or is requesting access to protected resources based on an authorization previously arranged with the authorization server.
当授权范围限于客户端控制下的受保护资源或先前与授权服务器一起安排的受保护资源时，客户端凭据（或其他形式的客户端身份验证）可以用作授权授予。客户机凭据通常在客户机代表其自身（客户机也是资源所有者）或基于先前与授权服务器安排的授权请求访问受保护资源时用作授权授予。
Access tokens are credentials used to access protected resources. An access token is a string representing an authorization issued to the client. The string is usually opaque to the client. Tokens represent specific scopes and durations of access, granted by the resource owner, and enforced by the resource server and authorization server.
访问令牌是用于访问受保护资源的凭据。访问令牌是表示颁发给客户端的授权的字符串。字符串对于客户端通常是不透明的。令牌表示特定的访问范围和持续时间，由资源所有者授予，并由资源服务器和授权服务器强制执行。
The token may denote an identifier used to retrieve the authorization information or may self-contain the authorization information in a verifiable manner (i.e., a token string consisting of some data and a signature). Additional authentication credentials, which are beyond the scope of this specification, may be required in order for the client to use a token.
令牌可以表示用于检索授权信息的标识符，或者可以以可验证的方式（即，由一些数据和签名组成的令牌字符串）自包含授权信息。为了让客户端使用令牌，可能需要额外的身份验证凭据，这些凭据超出了本规范的范围。
The access token provides an abstraction layer, replacing different authorization constructs (e.g., username and password) with a single token understood by the resource server. This abstraction enables issuing access tokens more restrictive than the authorization grant used to obtain them, as well as removing the resource server's need to understand a wide range of authentication methods.
访问令牌提供了一个抽象层，将不同的授权构造（例如用户名和密码）替换为资源服务器可以理解的单个令牌。这种抽象使得发布访问令牌比用于获取它们的授权授权更具限制性，并且消除了资源服务器理解各种身份验证方法的需要。
Access tokens can have different formats, structures, and methods of utilization (e.g., cryptographic properties) based on the resource server security requirements. Access token attributes and the methods used to access protected resources are beyond the scope of this specification and are defined by companion specifications such as [RFC6750].
根据资源服务器安全要求，访问令牌可以具有不同的格式、结构和使用方法（例如，加密属性）。访问令牌属性和用于访问受保护资源的方法超出了本规范的范围，并由相关规范（如[RFC6750]）定义。
Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires, or to obtain additional access tokens with identical or narrower scope (access tokens may have a shorter lifetime and fewer permissions than authorized by the resource owner). Issuing a refresh token is optional at the discretion of the authorization server. If the authorization server issues a refresh token, it is included when issuing an access token (i.e., step (D) in Figure 1).
刷新令牌是用于获取访问令牌的凭据。刷新令牌由授权服务器颁发给客户端，用于在当前访问令牌无效或过期时获取新的访问令牌，或获取范围相同或更窄的其他访问令牌（访问令牌的生存期和权限可能比资源所有者授权的要短）。由授权服务器决定是否发布刷新令牌是可选的。如果授权服务器发出刷新令牌，则在发出访问令牌时会包括该令牌（即图1中的步骤（D））。
A refresh token is a string representing the authorization granted to the client by the resource owner. The string is usually opaque to the client. The token denotes an identifier used to retrieve the
刷新令牌是一个字符串，表示资源所有者授予客户端的授权。字符串对于客户端通常是不透明的。该标记表示用于检索标记的标识符
authorization information. Unlike access tokens, refresh tokens are intended for use only with authorization servers and are never sent to resource servers.
授权信息。与访问令牌不同，刷新令牌仅用于授权服务器，从不发送到资源服务器。
+--------+ +---------------+
| |--(A)------- Authorization Grant --------->| |
| | | |
| |<-(B)----------- Access Token -------------| |
| | & Refresh Token | |
| | | |
| | +----------+ | |
| |--(C)---- Access Token ---->| | | |
| | | | | |
| |<-(D)- Protected Resource --| Resource | | Authorization |
| Client | | Server | | Server |
| |--(E)---- Access Token ---->| | | |
| | | | | |
| |<-(F)- Invalid Token Error -| | | |
| | +----------+ | |
| | | |
| |--(G)----------- Refresh Token ----------->| |
| | | |
| |<-(H)----------- Access Token -------------| |
+--------+ & Optional Refresh Token +---------------+
+--------+ +---------------+
| |--(A)------- Authorization Grant --------->| |
| | | |
| |<-(B)----------- Access Token -------------| |
| | & Refresh Token | |
| | | |
| | +----------+ | |
| |--(C)---- Access Token ---->| | | |
| | | | | |
| |<-(D)- Protected Resource --| Resource | | Authorization |
| Client | | Server | | Server |
| |--(E)---- Access Token ---->| | | |
| | | | | |
| |<-(F)- Invalid Token Error -| | | |
| | +----------+ | |
| | | |
| |--(G)----------- Refresh Token ----------->| |
| | | |
| |<-(H)----------- Access Token -------------| |
+--------+ & Optional Refresh Token +---------------+
Figure 2: Refreshing an Expired Access Token
图2：刷新过期的访问令牌
The flow illustrated in Figure 2 includes the following steps:
图2中所示的流程包括以下步骤：
(A) The client requests an access token by authenticating with the authorization server and presenting an authorization grant.
（A） 客户端通过与授权服务器进行身份验证并提供授权授予来请求访问令牌。
(B) The authorization server authenticates the client and validates the authorization grant, and if valid, issues an access token and a refresh token.
（B） 授权服务器对客户端进行身份验证并验证授权授予，如果有效，则发出访问令牌和刷新令牌。
(C) The client makes a protected resource request to the resource server by presenting the access token.
（C） 客户端通过提供访问令牌向资源服务器发出受保护的资源请求。
(D) The resource server validates the access token, and if valid, serves the request.
（D） 资源服务器验证访问令牌，如果有效，则为请求提供服务。
(E) Steps (C) and (D) repeat until the access token expires. If the client knows the access token expired, it skips to step (G); otherwise, it makes another protected resource request.
（E） 重复步骤（C）和（D），直到访问令牌到期。如果客户端知道访问令牌已过期，则跳到步骤（G）；否则，它会发出另一个受保护的资源请求。
(F) Since the access token is invalid, the resource server returns an invalid token error.
（F） 由于访问令牌无效，资源服务器返回无效令牌错误。
(G) The client requests a new access token by authenticating with the authorization server and presenting the refresh token. The client authentication requirements are based on the client type and on the authorization server policies.
（G） 客户端通过使用授权服务器进行身份验证并显示刷新令牌来请求新的访问令牌。客户端身份验证要求基于客户端类型和授权服务器策略。
(H) The authorization server authenticates the client and validates the refresh token, and if valid, issues a new access token (and, optionally, a new refresh token).
（H） 授权服务器对客户端进行身份验证并验证刷新令牌，如果有效，则发出新的访问令牌（以及，可选的，新的刷新令牌）。
Steps (C), (D), (E), and (F) are outside the scope of this specification, as described in Section 7.
如第7节所述，步骤（C）、（D）、（E）和（F）不在本规范的范围内。
Whenever Transport Layer Security (TLS) is used by this specification, the appropriate version (or versions) of TLS will vary over time, based on the widespread deployment and known security vulnerabilities. At the time of this writing, TLS version 1.2 [RFC5246] is the most recent version, but has a very limited deployment base and might not be readily available for implementation. TLS version 1.0 [RFC2246] is the most widely deployed version and will provide the broadest interoperability.
每当本规范使用传输层安全性（TLS）时，TLS的适当版本（或多个版本）将随着时间的推移而变化，这取决于广泛的部署和已知的安全漏洞。在撰写本文时，TLS版本1.2[RFC5246]是最新版本，但部署基础非常有限，可能无法立即实现。TLS版本1.0[RFC2246]是部署最广泛的版本，将提供最广泛的互操作性。
Implementations MAY also support additional transport-layer security mechanisms that meet their security requirements.
实现还可以支持满足其安全需求的其他传输层安全机制。
This specification makes extensive use of HTTP redirections, in which the client or the authorization server directs the resource owner's user-agent to another destination. While the examples in this specification show the use of the HTTP 302 status code, any other method available via the user-agent to accomplish this redirection is allowed and is considered to be an implementation detail.
此规范广泛使用HTTP重定向，其中客户端或授权服务器将资源所有者的用户代理定向到另一个目标。虽然本规范中的示例显示了HTTP 302状态代码的使用，但允许通过用户代理实现此重定向的任何其他方法，并将其视为实现细节。
OAuth 2.0 provides a rich authorization framework with well-defined security properties. However, as a rich and highly extensible framework with many optional components, on its own, this specification is likely to produce a wide range of non-interoperable implementations.
OAuth2.0提供了一个具有定义良好的安全属性的丰富授权框架。然而，作为一个包含许多可选组件的丰富且高度可扩展的框架，本规范本身可能会产生大量不可互操作的实现。
In addition, this specification leaves a few required components partially or fully undefined (e.g., client registration, authorization server capabilities, endpoint discovery). Without
此外，本规范保留了一些部分或完全未定义的必需组件（例如，客户端注册、授权服务器功能、端点发现）。没有
these components, clients must be manually and specifically configured against a specific authorization server and resource server in order to interoperate.
这些组件、客户端必须针对特定授权服务器和资源服务器进行手动和特定配置，以便进行互操作。
This framework was designed with the clear expectation that future work will define prescriptive profiles and extensions necessary to achieve full web-scale interoperability.
该框架的设计明确预期，未来的工作将定义实现完整web级互操作性所需的规范性概要文件和扩展。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in [RFC2119].
本规范中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234]. Additionally, the rule URI-reference is included from "Uniform Resource Identifier (URI): Generic Syntax" [RFC3986].
本规范使用[RFC5234]的增广巴科斯诺尔形式（ABNF）符号。此外，规则URI引用包含在“统一资源标识符（URI）：通用语法”[RFC3986]中。
Certain security-related terms are to be understood in the sense defined in [RFC4949]. These terms include, but are not limited to, "attack", "authentication", "authorization", "certificate", "confidentiality", "credential", "encryption", "identity", "sign", "signature", "trust", "validate", and "verify".
某些安全相关术语应理解为[RFC4949]中定义的含义。这些术语包括但不限于“攻击”、“认证”、“授权”、“证书”、“机密性”、“凭证”、“加密”、“身份”、“签名”、“签名”、“信任”、“验证”和“验证”。
Unless otherwise noted, all the protocol parameter names and values are case sensitive.
除非另有说明，否则所有协议参数名称和值都区分大小写。
Before initiating the protocol, the client registers with the authorization server. The means through which the client registers with the authorization server are beyond the scope of this specification but typically involve end-user interaction with an HTML registration form.
在启动协议之前，客户机向授权服务器注册。客户端向授权服务器注册的方式超出了本规范的范围，但通常涉及最终用户与HTML注册表单的交互。
Client registration does not require a direct interaction between the client and the authorization server. When supported by the authorization server, registration can rely on other means for establishing trust and obtaining the required client properties (e.g., redirection URI, client type). For example, registration can be accomplished using a self-issued or third-party-issued assertion, or by the authorization server performing client discovery using a trusted channel.
客户端注册不需要客户端和授权服务器之间的直接交互。当授权服务器支持时，注册可以依赖于其他方法来建立信任和获取所需的客户端属性（例如，重定向URI、客户端类型）。例如，可以使用自发布或第三方发布的断言来完成注册，或者通过授权服务器使用可信通道执行客户端发现来完成注册。
When registering a client, the client developer SHALL:
注册客户时，客户开发商应：
o specify the client type as described in Section 2.1,
o 指定第2.1节中所述的客户机类型，
o provide its client redirection URIs as described in Section 3.1.2, and
o 按照第3.1.2节所述提供其客户端重定向URI，以及
o include any other information required by the authorization server (e.g., application name, website, description, logo image, the acceptance of legal terms).
o 包括授权服务器要求的任何其他信息（例如，应用程序名称、网站、说明、徽标图像、法律条款的接受情况）。
OAuth defines two client types, based on their ability to authenticate securely with the authorization server (i.e., ability to maintain the confidentiality of their client credentials):
OAuth定义了两种客户端类型，基于它们与授权服务器安全地进行身份验证的能力（即维护其客户端凭据机密性的能力）：
confidential Clients capable of maintaining the confidentiality of their credentials (e.g., client implemented on a secure server with restricted access to the client credentials), or capable of secure client authentication using other means.
能够维护其凭据机密性的机密客户端（例如，在对客户端凭据访问受限的安全服务器上实现的客户端），或能够使用其他方式进行安全客户端身份验证的机密客户端。
public Clients incapable of maintaining the confidentiality of their credentials (e.g., clients executing on the device used by the resource owner, such as an installed native application or a web browser-based application), and incapable of secure client authentication via any other means.
公共客户端无法维护其凭据的机密性（例如，在资源所有者使用的设备上执行的客户端，例如安装的本机应用程序或基于web浏览器的应用程序），并且无法通过任何其他方式进行安全的客户端身份验证。
The client type designation is based on the authorization server's definition of secure authentication and its acceptable exposure levels of client credentials. The authorization server SHOULD NOT make assumptions about the client type.
客户端类型指定基于授权服务器的安全身份验证定义及其可接受的客户端凭据公开级别。授权服务器不应对客户端类型进行假设。
A client may be implemented as a distributed set of components, each with a different client type and security context (e.g., a distributed client with both a confidential server-based component and a public browser-based component). If the authorization server does not provide support for such clients or does not provide guidance with regard to their registration, the client SHOULD register each component as a separate client.
客户机可以实现为一组分布式组件，每个组件具有不同的客户机类型和安全上下文（例如，同时具有基于机密服务器的组件和基于公共浏览器的组件的分布式客户机）。如果授权服务器不支持此类客户机或不提供有关其注册的指导，则客户机应将每个组件注册为单独的客户机。
This specification has been designed around the following client profiles:
本规范是围绕以下客户概要文件设计的：
web application A web application is a confidential client running on a web server. Resource owners access the client via an HTML user interface rendered in a user-agent on the device used by the resource owner. The client credentials as well as any access token issued to the client are stored on the web server and are not exposed to or accessible by the resource owner.
web应用程序web应用程序是运行在web服务器上的机密客户端。资源所有者通过在资源所有者使用的设备上的用户代理中呈现的HTML用户界面访问客户端。客户端凭据以及颁发给客户端的任何访问令牌都存储在web服务器上，资源所有者不能公开或访问它们。
user-agent-based application A user-agent-based application is a public client in which the client code is downloaded from a web server and executes within a user-agent (e.g., web browser) on the device used by the resource owner. Protocol data and credentials are easily accessible (and often visible) to the resource owner. Since such applications reside within the user-agent, they can make seamless use of the user-agent capabilities when requesting authorization.
基于用户代理的应用程序基于用户代理的应用程序是公共客户端，其中客户端代码从web服务器下载，并在资源所有者使用的设备上的用户代理（例如，web浏览器）内执行。协议数据和凭据对于资源所有者来说很容易访问（并且经常可见）。由于此类应用程序驻留在用户代理中，因此它们可以在请求授权时无缝地使用用户代理功能。
native application A native application is a public client installed and executed on the device used by the resource owner. Protocol data and credentials are accessible to the resource owner. It is assumed that any client authentication credentials included in the application can be extracted. On the other hand, dynamically issued credentials such as access tokens or refresh tokens can receive an acceptable level of protection. At a minimum, these credentials are protected from hostile servers with which the application may interact. On some platforms, these credentials might be protected from other applications residing on the same device.
本机应用程序本机应用程序是在资源所有者使用的设备上安装和执行的公共客户端。资源所有者可以访问协议数据和凭据。假定可以提取应用程序中包含的任何客户端身份验证凭据。另一方面，动态颁发的凭据（如访问令牌或刷新令牌）可以获得可接受的保护级别。至少，这些凭据受到保护，不受应用程序可能与之交互的恶意服务器的攻击。在某些平台上，这些凭据可能受到保护，不受驻留在同一设备上的其他应用程序的影响。
The authorization server issues the registered client a client identifier -- a unique string representing the registration information provided by the client. The client identifier is not a secret; it is exposed to the resource owner and MUST NOT be used alone for client authentication. The client identifier is unique to the authorization server.
授权服务器向注册的客户机发出一个客户机标识符——一个表示客户机提供的注册信息的唯一字符串。客户端标识符不是秘密；它向资源所有者公开，不能单独用于客户端身份验证。客户端标识符对于授权服务器是唯一的。
The client identifier string size is left undefined by this specification. The client should avoid making assumptions about the identifier size. The authorization server SHOULD document the size of any identifier it issues.
此规范未定义客户端标识符字符串大小。客户应避免对标识符大小进行假设。授权服务器应该记录它发出的任何标识符的大小。
If the client type is confidential, the client and authorization server establish a client authentication method suitable for the security requirements of the authorization server. The authorization server MAY accept any form of client authentication meeting its security requirements.
如果客户端类型是机密的，则客户端和授权服务器将建立适合授权服务器安全要求的客户端身份验证方法。授权服务器可以接受满足其安全要求的任何形式的客户端身份验证。
Confidential clients are typically issued (or establish) a set of client credentials used for authenticating with the authorization server (e.g., password, public/private key pair).
机密客户端通常被颁发（或建立）一组客户端凭据，用于使用授权服务器进行身份验证（例如，密码、公钥/私钥对）。
The authorization server MAY establish a client authentication method with public clients. However, the authorization server MUST NOT rely on public client authentication for the purpose of identifying the client.
授权服务器可以与公共客户端建立客户端认证方法。但是，授权服务器不得依赖公共客户端身份验证来识别客户端。
The client MUST NOT use more than one authentication method in each request.
客户端在每个请求中不得使用多个身份验证方法。
Clients in possession of a client password MAY use the HTTP Basic authentication scheme as defined in [RFC2617] to authenticate with the authorization server. The client identifier is encoded using the "application/x-www-form-urlencoded" encoding algorithm per Appendix B, and the encoded value is used as the username; the client password is encoded using the same algorithm and used as the password. The authorization server MUST support the HTTP Basic authentication scheme for authenticating clients that were issued a client password.
拥有客户机密码的客户机可以使用[RFC2617]中定义的HTTP基本身份验证方案向授权服务器进行身份验证。根据附录B，使用“application/x-www-form-urlencoded”编码算法对客户标识符进行编码，编码值用作用户名；客户端密码使用相同的算法编码并用作密码。授权服务器必须支持HTTP基本身份验证方案，以验证已颁发客户端密码的客户端。
For example (with extra line breaks for display purposes only):
例如（仅出于显示目的使用额外的换行符）：
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
Alternatively, the authorization server MAY support including the client credentials in the request-body using the following parameters:
或者，授权服务器可以支持使用以下参数在请求主体中包括客户端凭据：
client_id REQUIRED. The client identifier issued to the client during the registration process described by Section 2.2.
需要客户端id。在第2.2节所述的注册过程中发给客户的客户标识符。
client_secret REQUIRED. The client secret. The client MAY omit the parameter if the client secret is an empty string.
需要客户端密码。客户的秘密。如果客户机机密是空字符串，则客户机可能会忽略该参数。
Including the client credentials in the request-body using the two parameters is NOT RECOMMENDED and SHOULD be limited to clients unable to directly utilize the HTTP Basic authentication scheme (or other password-based HTTP authentication schemes). The parameters can only be transmitted in the request-body and MUST NOT be included in the request URI.
不建议使用这两个参数在请求正文中包含客户端凭据，并且应限于无法直接使用HTTP基本身份验证方案（或其他基于密码的HTTP身份验证方案）的客户端。参数只能在请求正文中传输，不能包含在请求URI中。
For example, a request to refresh an access token (Section 6) using the body parameters (with extra line breaks for display purposes only):
例如，使用主体参数刷新访问令牌（第6节）的请求（带有额外的换行符，仅用于显示目的）：
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=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
&client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw
grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
&client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw
The authorization server MUST require the use of TLS as described in Section 1.6 when sending requests using password authentication.
当使用密码身份验证发送请求时，授权服务器必须要求使用第1.6节所述的TLS。
Since this client authentication method involves a password, the authorization server MUST protect any endpoint utilizing it against brute force attacks.
由于此客户端身份验证方法涉及密码，因此授权服务器必须保护使用密码的任何端点免受暴力攻击。
The authorization server MAY support any suitable HTTP authentication scheme matching its security requirements. When using other authentication methods, the authorization server MUST define a mapping between the client identifier (registration record) and authentication scheme.
授权服务器可以支持与其安全要求匹配的任何合适的HTTP认证方案。使用其他身份验证方法时，授权服务器必须定义客户端标识符（注册记录）和身份验证方案之间的映射。
This specification does not exclude the use of unregistered clients. However, the use of such clients is beyond the scope of this specification and requires additional security analysis and review of its interoperability impact.
本规范不排除使用未注册的客户端。但是，此类客户端的使用超出了本规范的范围，需要对其互操作性影响进行额外的安全分析和审查。
The authorization process utilizes two authorization server endpoints (HTTP resources):
授权过程使用两个授权服务器端点（HTTP资源）：
o Authorization endpoint - used by the client to obtain authorization from the resource owner via user-agent redirection.
o 授权端点-客户端通过用户代理重定向从资源所有者处获取授权。
o Token endpoint - used by the client to exchange an authorization grant for an access token, typically with client authentication.
o 令牌端点-客户端用于交换访问令牌的授权授予，通常使用客户端身份验证。
As well as one client endpoint:
以及一个客户端端点：
o Redirection endpoint - used by the authorization server to return responses containing authorization credentials to the client via the resource owner user-agent.
o 重定向终结点—授权服务器用于通过资源所有者用户代理将包含授权凭据的响应返回给客户端。
Not every authorization grant type utilizes both endpoints. Extension grant types MAY define additional endpoints as needed.
并非每种授权授予类型都同时使用这两个端点。扩展授权类型可以根据需要定义其他端点。
The authorization endpoint is used to interact with the resource owner and obtain an authorization grant. The authorization server MUST first verify the identity of the resource owner. The way in which the authorization server authenticates the resource owner (e.g., username and password login, session cookies) is beyond the scope of this specification.
授权端点用于与资源所有者交互并获得授权授予。授权服务器必须首先验证资源所有者的身份。授权服务器验证资源所有者的方式（例如用户名和密码登录、会话cookie）超出了本规范的范围。
The means through which the client obtains the location of the authorization endpoint are beyond the scope of this specification, but the location is typically provided in the service documentation.
客户机获取授权端点位置的方法超出了本规范的范围，但该位置通常在服务文档中提供。
The endpoint URI MAY include an "application/x-www-form-urlencoded" formatted (per Appendix B) query component ([RFC3986] Section 3.4), which MUST be retained when adding additional query parameters. The endpoint URI MUST NOT include a fragment component.
端点URI可能包括一个“application/x-www-form-urlencoded”（根据附录B）格式的查询组件（[RFC3986]第3.4节），在添加其他查询参数时必须保留该组件。端点URI不得包含片段组件。
Since requests to the authorization endpoint result in user authentication and the transmission of clear-text credentials (in the HTTP response), the authorization server MUST require the use of TLS as described in Section 1.6 when sending requests to the authorization endpoint.
由于对授权端点的请求会导致用户身份验证和明文凭证的传输（在HTTP响应中），因此在向授权端点发送请求时，授权服务器必须要求使用第1.6节所述的TLS。
The authorization server MUST support the use of the HTTP "GET" method [RFC2616] for the authorization endpoint and MAY support the use of the "POST" method as well.
授权服务器必须支持对授权端点使用HTTP“GET”方法[RFC2616]，还可以支持使用“POST”方法。
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 authorization endpoint is used by the authorization code grant type and implicit grant type flows. The client informs the authorization server of the desired grant type using the following parameter:
授权端点由授权代码授权类型和隐式授权类型流使用。客户端使用以下参数通知授权服务器所需的授权类型：
response_type REQUIRED. The value MUST be one of "code" for requesting an authorization code as described by Section 4.1.1, "token" for requesting an access token (implicit grant) as described by Section 4.2.1, or a registered extension value as described by Section 8.4.
需要响应类型。该值必须是第4.1.1节所述的用于请求授权代码的“代码”、“第4.2.1节所述的用于请求访问令牌（隐式授权）的令牌”或第8.4节所述的注册扩展值之一。
Extension response types MAY contain a space-delimited (%x20) list of values, where the order of values does not matter (e.g., response type "a b" is the same as "b a"). The meaning of such composite response types is defined by their respective specifications.
扩展响应类型可能包含以空格分隔的（%x20）值列表，其中值的顺序无关紧要（例如，响应类型“ab”与“ba”相同）。此类复合响应类型的含义由其各自的规范定义。
If an authorization request is missing the "response_type" parameter, or if the response type is not understood, the authorization server MUST return an error response as described in Section 4.1.2.1.
如果授权请求缺少“response_type”参数，或者如果不理解响应类型，授权服务器必须返回错误响应，如第4.1.2.1节所述。
After completing its interaction with the resource owner, the authorization server directs the resource owner's user-agent back to the client. The authorization server redirects the user-agent to the client's redirection endpoint previously established with the authorization server during the client registration process or when making the authorization request.
完成与资源所有者的交互后，授权服务器将资源所有者的用户代理定向回客户端。授权服务器将用户代理重定向到以前在客户端注册过程中或发出授权请求时使用授权服务器建立的客户端重定向端点。
The redirection endpoint URI MUST be an absolute URI as defined by [RFC3986] Section 4.3. The endpoint URI MAY include an "application/x-www-form-urlencoded" formatted (per Appendix B) query component ([RFC3986] Section 3.4), which MUST be retained when adding additional query parameters. The endpoint URI MUST NOT include a fragment component.
重定向端点URI必须是[RFC3986]第4.3节定义的绝对URI。端点URI可能包括一个“application/x-www-form-urlencoded”（根据附录B）格式的查询组件（[RFC3986]第3.4节），在添加其他查询参数时必须保留该组件。端点URI不得包含片段组件。
The redirection endpoint SHOULD require the use of TLS as described in Section 1.6 when the requested response type is "code" or "token", or when the redirection request will result in the transmission of sensitive credentials over an open network. This specification does not mandate the use of TLS because at the time of this writing, requiring clients to deploy TLS is a significant hurdle for many client developers. If TLS is not available, the authorization server SHOULD warn the resource owner about the insecure endpoint prior to redirection (e.g., display a message during the authorization request).
当请求的响应类型为“代码”或“令牌”时，或者当重定向请求将导致通过开放网络传输敏感凭据时，重定向端点应要求使用第1.6节中所述的TLS。本规范并不强制使用TLS，因为在撰写本文时，要求客户机部署TLS对于许多客户机开发人员来说是一个重大障碍。如果TLS不可用，则授权服务器应在重定向之前就不安全端点向资源所有者发出警告（例如，在授权请求期间显示消息）。
Lack of transport-layer security can have a severe impact on the security of the client and the protected resources it is authorized to access. The use of transport-layer security is particularly critical when the authorization process is used as a form of delegated end-user authentication by the client (e.g., third-party sign-in service).
缺乏传输层安全性可能会严重影响客户端及其授权访问的受保护资源的安全性。当授权过程被客户端用作委托的最终用户身份验证形式（例如，第三方登录服务）时，传输层安全性的使用尤为关键。
The authorization server MUST require the following clients to register their redirection endpoint:
授权服务器必须要求以下客户端注册其重定向终结点：
o Public clients.
o 公众客户。
o Confidential clients utilizing the implicit grant type.
o 使用隐式授权类型的机密客户端。
The authorization server SHOULD require all clients to register their redirection endpoint prior to utilizing the authorization endpoint.
授权服务器应要求所有客户端在使用授权端点之前注册其重定向端点。
The authorization server SHOULD require the client to provide the complete redirection URI (the client MAY use the "state" request parameter to achieve per-request customization). If requiring the registration of the complete redirection URI is not possible, the authorization server SHOULD require the registration of the URI scheme, authority, and path (allowing the client to dynamically vary only the query component of the redirection URI when requesting authorization).
授权服务器应该要求客户端提供完整的重定向URI（客户端可以使用“state”请求参数来实现每个请求的定制）。如果无法要求注册完整的重定向URI，则授权服务器应要求注册URI方案、权限和路径（允许客户端在请求授权时仅动态更改重定向URI的查询组件）。
The authorization server MAY allow the client to register multiple redirection endpoints.
授权服务器可允许客户端注册多个重定向端点。
Lack of a redirection URI registration requirement can enable an attacker to use the authorization endpoint as an open redirector as described in Section 10.15.
如第10.15节所述，缺少重定向URI注册要求可使攻击者将授权端点用作打开的重定向器。
If multiple redirection URIs have been registered, if only part of the redirection URI has been registered, or if no redirection URI has been registered, the client MUST include a redirection URI with the authorization request using the "redirect_uri" request parameter.
如果已注册多个重定向URI，如果仅注册了部分重定向URI，或者如果未注册重定向URI，则客户端必须使用“redirect_URI”请求参数在授权请求中包含重定向URI。
When a redirection URI is included in an authorization request, the authorization server MUST compare and match the value received against at least one of the registered redirection URIs (or URI components) as defined in [RFC3986] Section 6, if any redirection URIs were registered. If the client registration included the full redirection URI, the authorization server MUST compare the two URIs using simple string comparison as defined in [RFC3986] Section 6.2.1.
当授权请求中包含重定向URI时，如果注册了任何重定向URI，授权服务器必须将收到的值与[RFC3986]第6节中定义的至少一个已注册重定向URI（或URI组件）进行比较和匹配。如果客户端注册包含完整重定向URI，则授权服务器必须使用[RFC3986]第6.2.1节中定义的简单字符串比较来比较这两个URI。
If an authorization request fails validation due to a missing, invalid, or mismatching redirection URI, the authorization server SHOULD inform the resource owner of the error and MUST NOT automatically redirect the user-agent to the invalid redirection URI.
如果由于重定向URI丢失、无效或不匹配而导致授权请求验证失败，则授权服务器应将错误通知资源所有者，并且不得自动将用户代理重定向到无效的重定向URI。
The redirection request to the client's endpoint typically results in an HTML document response, processed by the user-agent. If the HTML response is served directly as the result of the redirection request, any script included in the HTML document will execute with full access to the redirection URI and the credentials it contains.
对客户端端点的重定向请求通常会导致由用户代理处理的HTML文档响应。如果HTML响应直接作为重定向请求的结果提供，则HTML文档中包含的任何脚本都将在完全访问重定向URI及其包含的凭据的情况下执行。
The client SHOULD NOT include any third-party scripts (e.g., third-party analytics, social plug-ins, ad networks) in the redirection endpoint response. Instead, it SHOULD extract the credentials from the URI and redirect the user-agent again to another endpoint without exposing the credentials (in the URI or elsewhere). If third-party scripts are included, the client MUST ensure that its own scripts (used to extract and remove the credentials from the URI) will execute first.
客户端不应在重定向端点响应中包含任何第三方脚本（例如，第三方分析、社交插件、广告网络）。相反，它应该从URI中提取凭据，并将用户代理再次重定向到另一个端点，而不公开凭据（在URI中或其他地方）。如果包含第三方脚本，客户端必须确保首先执行自己的脚本（用于从URI提取和删除凭据）。
The token endpoint is used by the client to obtain an access token by presenting its authorization grant or refresh token. The token endpoint is used with every authorization grant except for the implicit grant type (since an access token is issued directly).
客户端使用令牌端点通过呈现其授权授予或刷新令牌来获取访问令牌。令牌端点用于除隐式授权类型之外的所有授权授权（因为直接发出访问令牌）。
The means through which the client obtains the location of the token endpoint are beyond the scope of this specification, but the location is typically provided in the service documentation.
客户机获取令牌端点位置的方法超出了本规范的范围，但该位置通常在服务文档中提供。
The endpoint URI MAY include an "application/x-www-form-urlencoded" formatted (per Appendix B) query component ([RFC3986] Section 3.4), which MUST be retained when adding additional query parameters. The endpoint URI MUST NOT include a fragment component.
端点URI可能包括一个“application/x-www-form-urlencoded”（根据附录B）格式的查询组件（[RFC3986]第3.4节），在添加其他查询参数时必须保留该组件。端点URI不得包含片段组件。
Since requests to the token endpoint result in the transmission of clear-text credentials (in the HTTP request and response), the authorization server MUST require the use of TLS as described in Section 1.6 when sending requests to the token endpoint.
由于对令牌端点的请求会导致明文凭证的传输（在HTTP请求和响应中），因此在向令牌端点发送请求时，授权服务器必须要求使用第1.6节所述的TLS。
The client MUST use the HTTP "POST" method when making access token requests.
客户端在发出访问令牌请求时必须使用HTTP“POST”方法。
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.
发送时不带值的参数必须视为从请求中省略了它们。授权服务器必须忽略无法识别的请求参数。请求和响应参数不能包含多次。
Confidential clients or other clients issued client credentials MUST authenticate with the authorization server as described in Section 2.3 when making requests to the token endpoint. Client authentication is used for:
当向令牌端点发出请求时，机密客户端或其他客户端颁发的客户端凭据必须按照第2.3节所述，通过授权服务器进行身份验证。客户端身份验证用于：
o Enforcing the binding of refresh tokens and authorization codes to the client they were issued to. Client authentication is critical when an authorization code is transmitted to the redirection endpoint over an insecure channel or when the redirection URI has not been registered in full.
o 强制将刷新令牌和授权代码绑定到向其颁发的客户端。当授权码通过不安全的通道传输到重定向端点，或者重定向URI尚未完全注册时，客户端身份验证至关重要。
o Recovering from a compromised client by disabling the client or changing its credentials, thus preventing an attacker from abusing stolen refresh tokens. Changing a single set of client credentials is significantly faster than revoking an entire set of refresh tokens.
o 通过禁用客户端或更改其凭据从受损客户端恢复，从而防止攻击者滥用窃取的刷新令牌。更改一组客户端凭据要比撤消一整套刷新令牌快得多。
o Implementing authentication management best practices, which require periodic credential rotation. Rotation of an entire set of refresh tokens can be challenging, while rotation of a single set of client credentials is significantly easier.
o 实施身份验证管理最佳实践，这需要定期轮换凭证。轮换一整套刷新令牌可能是一个挑战，而轮换一组客户端凭据则要容易得多。
A client MAY use the "client_id" request parameter to identify itself when sending requests to the token endpoint. In the "authorization_code" "grant_type" request to the token endpoint, an unauthenticated client MUST send its "client_id" to prevent itself from inadvertently accepting a code intended for a client with a different "client_id". This protects the client from substitution of the authentication code. (It provides no additional security for the protected resource.)
当向令牌端点发送请求时，客户端可以使用“client_id”请求参数来标识自身。在对令牌端点的“授权\代码”“授予\类型”请求中，未经身份验证的客户端必须发送其“客户端\ id”，以防止自己无意中接受用于具有不同“客户端\ id”的客户端的代码。这可以保护客户端不被身份验证代码替换。（它不为受保护的资源提供额外的安全性。）
The authorization and token endpoints allow the client to specify the scope of the access request using the "scope" request parameter. In turn, the authorization server uses the "scope" response parameter to inform the client of the scope of the access token issued.
授权和令牌端点允许客户端使用“scope”请求参数指定访问请求的范围。反过来，授权服务器使用“scope”响应参数通知客户机所发出的访问令牌的范围。
The value of the scope parameter is expressed as a list of space-delimited, case-sensitive strings. The strings are defined by the authorization server. If the value contains multiple space-delimited strings, their order does not matter, and each string adds an additional access range to the requested scope.
scope参数的值表示为空格分隔、区分大小写的字符串列表。这些字符串由授权服务器定义。如果该值包含多个空格分隔的字符串，则它们的顺序无关紧要，每个字符串都会向请求的范围添加一个额外的访问范围。
scope = scope-token *( SP scope-token )
scope-token = 1*( %x21 / %x23-5B / %x5D-7E )
scope = scope-token *( SP scope-token )
scope-token = 1*( %x21 / %x23-5B / %x5D-7E )
The authorization server MAY fully or partially ignore the scope requested by the client, based on the authorization server policy or the resource owner's instructions. If the issued access token scope is different from the one requested by the client, the authorization server MUST include the "scope" response parameter to inform the client of the actual scope granted.
根据授权服务器策略或资源所有者的指示，授权服务器可以完全或部分忽略客户端请求的范围。如果颁发的访问令牌作用域与客户端请求的作用域不同，则授权服务器必须包含“scope”响应参数，以通知客户端实际授予的作用域。
If the client omits the scope parameter when requesting authorization, the authorization server MUST either process the request using a pre-defined default value or fail the request indicating an invalid scope. The authorization server SHOULD document its scope requirements and default value (if defined).
如果客户端在请求授权时忽略了scope参数，则授权服务器必须使用预定义的默认值处理该请求，或者使指示无效作用域的请求失败。授权服务器应记录其范围要求和默认值（如果定义）。
To request an access token, the client obtains authorization from the resource owner. The authorization is expressed in the form of an authorization grant, which the client uses to request the access token. OAuth defines four grant types: authorization code, implicit, resource owner password credentials, and client credentials. It also provides an extension mechanism for defining additional grant types.
为了请求访问令牌，客户端从资源所有者处获得授权。授权以授权授权的形式表示，客户端使用授权授权请求访问令牌。OAuth定义了四种授权类型：授权代码、隐式、资源所有者密码凭据和客户端凭据。它还提供了一种扩展机制来定义额外的授权类型。
The authorization code grant type is used to obtain both access tokens and refresh tokens and is optimized for confidential clients. Since this is a redirection-based flow, the client must be capable of interacting with the resource owner's user-agent (typically a web browser) and capable of receiving incoming requests (via redirection) from the authorization server.
授权码授权类型用于获取访问令牌和刷新令牌，并针对机密客户端进行了优化。由于这是一个基于重定向的流，因此客户端必须能够与资源所有者的用户代理（通常是web浏览器）交互，并能够接收来自授权服务器的传入请求（通过重定向）。
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI ---->| |
| User- | | Authorization |
| Agent -+----(B)-- User authenticates --->| Server |
| | | |
| -+----(C)-- Authorization Code ---<| |
+-|----|---+ +---------------+
| | ^ v
(A) (C) | |
| | | |
^ v | |
+---------+ | |
| |>---(D)-- Authorization Code ---------' |
| Client | & Redirection URI |
| | |
| |<---(E)----- Access Token -------------------'
+---------+ (w/ Optional Refresh Token)
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI ---->| |
| User- | | Authorization |
| Agent -+----(B)-- User authenticates --->| Server |
| | | |
| -+----(C)-- Authorization Code ---<| |
+-|----|---+ +---------------+
| | ^ v
(A) (C) | |
| | | |
^ v | |
+---------+ | |
| |>---(D)-- Authorization Code ---------' |
| Client | & Redirection URI |
| | |
| |<---(E)----- Access Token -------------------'
+---------+ (w/ Optional Refresh Token)
Note: The lines illustrating steps (A), (B), and (C) are broken into two parts as they pass through the user-agent.
注意：说明步骤（A）、（B）和（C）的行在通过用户代理时分为两部分。
Figure 3: Authorization Code Flow
图3：授权代码流
The flow illustrated in Figure 3 includes the following steps:
图3所示的流程包括以下步骤：
(A) The client initiates the flow by directing the resource owner's user-agent to the authorization endpoint. The client includes its client identifier, requested scope, local state, and a redirection URI to which the authorization server will send the user-agent back once access is granted (or denied).
（A） 客户端通过将资源所有者的用户代理定向到授权端点来启动流。客户机包括其客户机标识符、请求的作用域、本地状态和重定向URI，一旦授予（或拒绝）访问权限，授权服务器将向其发回用户代理。
(B) The authorization server authenticates the resource owner (via the user-agent) and establishes whether the resource owner grants or denies the client's access request.
（B） 授权服务器（通过用户代理）验证资源所有者，并确定资源所有者是批准还是拒绝客户端的访问请求。
(C) Assuming the resource owner grants access, the authorization server redirects the user-agent back to the client using the redirection URI provided earlier (in the request or during client registration). The redirection URI includes an authorization code and any local state provided by the client earlier.
（C） 假设资源所有者授予访问权限，授权服务器使用前面提供的重定向URI（在请求中或在客户端注册期间）将用户代理重定向回客户端。重定向URI包括授权代码和客户端先前提供的任何本地状态。
(D) The client requests an access token from the authorization server's token endpoint by including the authorization code received in the previous step. When making the request, the client authenticates with the authorization server. The client includes the redirection URI used to obtain the authorization code for verification.
（D） 客户端通过包括在上一步中接收到的授权代码，从授权服务器的令牌端点请求访问令牌。发出请求时，客户机通过授权服务器进行身份验证。客户端包括用于获取验证授权代码的重定向URI。
(E) The authorization server authenticates the client, validates the authorization code, and ensures that the redirection URI received matches the URI used to redirect the client in step (C). If valid, the authorization server responds back with an access token and, optionally, a refresh token.
（E） 授权服务器验证客户端，验证授权代码，并确保接收到的重定向URI与步骤（C）中用于重定向客户端的URI匹配。如果有效，授权服务器将使用访问令牌和刷新令牌（可选）进行响应。
The client constructs the request URI by adding the following parameters to the query component of the authorization endpoint URI using the "application/x-www-form-urlencoded" format, per Appendix B:
根据附录B，客户机通过使用“application/x-www-form-urlencoded”格式向授权端点URI的查询组件添加以下参数来构造请求URI：
response_type REQUIRED. Value MUST be set to "code".
需要响应类型。值必须设置为“代码”。
client_id REQUIRED. The client identifier as described in Section 2.2.
需要客户端id。第2.2节所述的客户标识符。
redirect_uri OPTIONAL. As described in Section 3.1.2.
重定向uri是可选的。如第3.1.2节所述。
scope OPTIONAL. The scope of the access request as described by Section 3.3.
范围可选。访问请求的范围如第3.3节所述。
state RECOMMENDED. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The parameter SHOULD be used for preventing cross-site request forgery as described in Section 10.12.
国家建议。客户端用于维护请求和回调之间的状态的不透明值。授权服务器在将用户代理重定向回客户端时包含此值。该参数应用于防止跨站点请求伪造，如第10.12节所述。
The client directs the resource owner to the constructed URI using an HTTP redirection response, or by other means available to it via the user-agent.
客户端使用HTTP重定向响应或通过用户代理提供的其他方式将资源所有者定向到构造的URI。
For example, the client directs the user-agent to make the following HTTP request using TLS (with extra line breaks for display purposes only):
例如，客户端指示用户代理使用TLS发出以下HTTP请求（额外的换行符仅用于显示目的）：
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
The authorization server validates the request to ensure that all required parameters are present and valid. If the request is valid, the authorization server authenticates the resource owner and obtains an authorization decision (by asking the resource owner or by establishing approval via other means).
授权服务器验证请求，以确保所有必需的参数都存在且有效。如果请求有效，则授权服务器验证资源所有者并获得授权决策（通过询问资源所有者或通过其他方式建立批准）。
When a decision is established, the authorization server directs the user-agent to the provided client redirection URI using an HTTP redirection response, or by other means available to it via the user-agent.
当确定决策时，授权服务器使用HTTP重定向响应或通过用户代理可用的其他方式将用户代理定向到提供的客户端重定向URI。
If the resource owner grants the access request, the authorization server issues an authorization code and delivers it to the client by adding the following parameters to the query component of the redirection URI using the "application/x-www-form-urlencoded" format, per Appendix B:
如果资源所有者授予访问请求，授权服务器将发出授权代码，并通过使用“application/x-www-form-urlencoded”格式（见附录B）向重定向URI的查询组件添加以下参数，将其发送给客户端：
code REQUIRED. The authorization code generated by the authorization server. The authorization code MUST expire shortly after it is issued to mitigate the risk of leaks. A maximum authorization code lifetime of 10 minutes is RECOMMENDED. The client MUST NOT use the authorization code
代码是必需的。由授权服务器生成的授权代码。授权码必须在发布后不久过期，以降低泄漏风险。建议授权代码的最长生存时间为10分钟。客户不得使用授权代码
more than once. If an authorization code is used more than once, the authorization server MUST deny the request and SHOULD revoke (when possible) all tokens previously issued based on that authorization code. The authorization code is bound to the client identifier and redirection URI.
不止一次。如果一个授权码被多次使用，授权服务器必须拒绝该请求，并应（在可能的情况下）撤销先前基于该授权码颁发的所有令牌。授权代码绑定到客户端标识符和重定向URI。
state REQUIRED if the "state" parameter was present in the client authorization request. The exact value received from the client.
如果客户端授权请求中存在“state”参数，则需要state。从客户端收到的确切值。
For example, the authorization server redirects the user-agent by sending the following HTTP response:
例如，授权服务器通过发送以下HTTP响应重定向用户代理：
HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
&state=xyz
HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
&state=xyz
The client MUST ignore unrecognized response parameters. The authorization code string size is left undefined by this specification. The client should avoid making assumptions about code value sizes. The authorization server SHOULD document the size of any value it issues.
客户端必须忽略无法识别的响应参数。本规范未定义授权码字符串大小。客户应避免对代码值大小进行假设。授权服务器应记录其发出的任何值的大小。
If the request fails due to a missing, invalid, or mismatching redirection URI, or if the client identifier is missing or invalid, the authorization server SHOULD inform the resource owner of the error and MUST NOT automatically redirect the user-agent to the invalid redirection URI.
如果由于重定向URI丢失、无效或不匹配而导致请求失败，或者如果客户端标识符丢失或无效，则授权服务器应将错误通知资源所有者，并且不得自动将用户代理重定向到无效的重定向URI。
If the resource owner denies the access request or if the request fails for reasons other than a missing or invalid redirection URI, the authorization server informs the client by adding the following parameters to the query component of the redirection URI using the "application/x-www-form-urlencoded" format, per Appendix B:
如果资源所有者拒绝访问请求，或者如果请求因缺少或无效重定向URI以外的原因而失败，授权服务器将根据附录B，通过使用“application/x-www-form-urlencoded”格式向重定向URI的查询组件添加以下参数来通知客户端：
error REQUIRED. A single ASCII [USASCII] error code from the following:
错误要求。一个ASCII[USASCII]错误代码来自以下代码：
invalid_request The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed.
无效的_请求请求缺少必需的参数、包含无效的参数值、多次包含参数或格式不正确。
unauthorized_client The client is not authorized to request an authorization code using this method.
未经授权的\u客户端未授权客户端使用此方法请求授权代码。
access_denied The resource owner or authorization server denied the request.
资源所有者或授权服务器拒绝了访问请求。
unsupported_response_type The authorization server does not support obtaining an authorization code using this method.
不支持的\u响应\u类型授权服务器不支持使用此方法获取授权代码。
invalid_scope The requested scope is invalid, unknown, or malformed.
无效\u作用域请求的作用域无效、未知或格式不正确。
server_error The authorization server encountered an unexpected condition that prevented it from fulfilling the request. (This error code is needed because a 500 Internal Server Error HTTP status code cannot be returned to the client via an HTTP redirect.)
服务器\错误授权服务器遇到意外情况，无法满足请求。（需要此错误代码，因为无法通过HTTP重定向将500内部服务器错误HTTP状态代码返回给客户端。）
temporarily_unavailable The authorization server is currently unable to handle the request due to a temporary overloading or maintenance of the server. (This error code is needed because a 503 Service Unavailable HTTP status code cannot be returned to the client via an HTTP redirect.)
暂时不可用由于服务器临时过载或维护，授权服务器当前无法处理请求。（需要此错误代码，因为无法通过HTTP重定向将503服务不可用HTTP状态代码返回给客户端。）
Values for the "error" parameter MUST NOT include characters outside the set %x20-21 / %x23-5B / %x5D-7E.
“error”参数的值不得包含集合%x20-21/%x23-5B/%x5D-7E之外的字符。
error_description OPTIONAL. Human-readable ASCII [USASCII] text providing additional information, used to assist the client developer in understanding the error that occurred. Values for the "error_description" parameter MUST NOT include characters outside the set %x20-21 / %x23-5B / %x5D-7E.
错误描述是可选的。人类可读的ASCII[USASCI]文本，提供附加信息，用于帮助客户机开发人员理解发生的错误。“error_description”参数的值不得包含集合%x20-21/%x23-5B/%x5D-7E之外的字符。
error_uri OPTIONAL. A URI identifying a human-readable web page with information about the error, used to provide the client developer with additional information about the error. Values for the "error_uri" parameter MUST conform to the URI-reference syntax and thus MUST NOT include characters outside the set %x21 / %x23-5B / %x5D-7E.
错误\u uri可选。一种URI，用错误信息标识人类可读的网页，用于向客户端开发人员提供有关错误的附加信息。“error_uri”参数的值必须符合uri引用语法，因此不能包含集合%x21/%x23-5B/%x5D-7E之外的字符。
state REQUIRED if a "state" parameter was present in the client authorization request. The exact value received from the client.
如果客户端授权请求中存在“状态”参数，则需要状态。从客户端收到的确切值。
For example, the authorization server redirects the user-agent by sending the following HTTP response:
例如，授权服务器通过发送以下HTTP响应重定向用户代理：
HTTP/1.1 302 Found
Location: https://client.example.com/cb?error=access_denied&state=xyz
HTTP/1.1 302 Found
Location: https://client.example.com/cb?error=access_denied&state=xyz
The client makes a request to the token endpoint by sending the following parameters using the "application/x-www-form-urlencoded" format per Appendix B with a character encoding of UTF-8 in the HTTP request entity-body:
客户端通过使用附录B中的“application/x-www-form-urlencoded”格式发送以下参数向令牌端点发出请求，HTTP请求实体正文中的字符编码为UTF-8：
grant_type REQUIRED. Value MUST be set to "authorization_code".
授权类型是必需的。值必须设置为“授权\代码”。
code REQUIRED. The authorization code received from the authorization server.
代码是必需的。从授权服务器接收的授权代码。
redirect_uri REQUIRED, if the "redirect_uri" parameter was included in the authorization request as described in Section 4.1.1, and their values MUST be identical.
如果“redirect_uri”参数包含在第4.1.1节所述的授权请求中，且其值必须相同，则需要redirect_uri。
client_id REQUIRED, if the client is not authenticating with the authorization server as described in Section 3.2.1.
如果客户端未按照第3.2.1节所述使用授权服务器进行身份验证，则需要客户端id。
If the client type is confidential or 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.
如果客户机类型是机密的，或者客户机被颁发了客户机凭据（或分配了其他身份验证要求），则客户机必须按照第3.2.1节中的说明向授权服务器进行身份验证。
For example, the client makes the following HTTP request using TLS (with extra line breaks for display purposes only):
例如，客户端使用TLS发出以下HTTP请求（带有额外的换行符，仅用于显示目的）：
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=https%3A%2F%2Fclient%2ecample%2Ecom%2Fcb
The authorization server MUST:
授权服务器必须：
o require client authentication for confidential clients or for any client that was issued client credentials (or with other authentication requirements),
o 要求对机密客户或任何获得客户凭证的客户进行客户身份验证（或符合其他身份验证要求），
o authenticate the client if client authentication is included,
o 如果包括客户端身份验证，则对客户端进行身份验证，
o ensure that the authorization code was issued to the authenticated confidential client, or if the client is public, ensure that the code was issued to "client_id" in the request,
o 确保授权代码已颁发给认证的保密客户，或者如果客户是公开的，则确保该代码已颁发给请求中的“客户id”，
o verify that the authorization code is valid, and
o 验证授权代码是否有效，以及
o ensure that the "redirect_uri" parameter is present if the "redirect_uri" parameter was included in the initial authorization request as described in Section 4.1.1, and if included ensure that their values are identical.
o 如第4.1.1节所述，如果初始授权请求中包含“redirect_uri”参数，请确保“redirect_uri”参数存在，如果包含，请确保其值相同。
If the access token request is valid and authorized, the authorization server issues an access token and optional refresh token as described in Section 5.1. If the request client authentication failed or is invalid, the authorization server returns an error response as described in Section 5.2.
如果访问令牌请求有效且已授权，则授权服务器将发出访问令牌和可选刷新令牌，如第5.1节所述。如果请求客户端身份验证失败或无效，授权服务器将返回错误响应，如第5.2节所述。
An example successful response:
成功响应的一个示例：
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
The implicit grant type is used to obtain access tokens (it does not support the issuance of refresh tokens) and is optimized for public clients known to operate a particular redirection URI. These clients are typically implemented in a browser using a scripting language such as JavaScript.
隐式授权类型用于获取访问令牌（它不支持发布刷新令牌），并针对已知操作特定重定向URI的公共客户端进行了优化。这些客户端通常使用脚本语言（如JavaScript）在浏览器中实现。
Since this is a redirection-based flow, the client must be capable of interacting with the resource owner's user-agent (typically a web browser) and capable of receiving incoming requests (via redirection) from the authorization server.
由于这是一个基于重定向的流，因此客户端必须能够与资源所有者的用户代理（通常是web浏览器）交互，并能够接收来自授权服务器的传入请求（通过重定向）。
Unlike the authorization code grant type, in which the client makes separate requests for authorization and for an access token, the client receives the access token as the result of the authorization request.
与授权码授予类型不同，在授权码授予类型中，客户端分别请求授权和访问令牌，客户端接收访问令牌作为授权请求的结果。
The implicit grant type does not include client authentication, and relies on the presence of the resource owner and the registration of the redirection URI. Because the access token is encoded into the redirection URI, it may be exposed to the resource owner and other applications residing on the same device.
隐式授权类型不包括客户端身份验证，它依赖于资源所有者的存在和重定向URI的注册。由于访问令牌被编码到重定向URI中，因此它可能会暴露给资源所有者和驻留在同一设备上的其他应用程序。
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI --->| |
| User- | | Authorization |
| Agent -|----(B)-- User authenticates -->| Server |
| | | |
| |<---(C)--- Redirection URI ----<| |
| | with Access Token +---------------+
| | in Fragment
| | +---------------+
| |----(D)--- Redirection URI ---->| Web-Hosted |
| | without Fragment | Client |
| | | Resource |
| (F) |<---(E)------- Script ---------<| |
| | +---------------+
+-|--------+
| |
(A) (G) Access Token
| |
^ v
+---------+
| |
| Client |
| |
+---------+
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI --->| |
| User- | | Authorization |
| Agent -|----(B)-- User authenticates -->| Server |
| | | |
| |<---(C)--- Redirection URI ----<| |
| | with Access Token +---------------+
| | in Fragment
| | +---------------+
| |----(D)--- Redirection URI ---->| Web-Hosted |
| | without Fragment | Client |
| | | Resource |
| (F) |<---(E)------- Script ---------<| |
| | +---------------+
+-|--------+
| |
(A) (G) Access Token
| |
^ v
+---------+
| |
| Client |
| |
+---------+
Note: The lines illustrating steps (A) and (B) are broken into two parts as they pass through the user-agent.
注意：说明步骤（A）和（B）的行在通过用户代理时分为两部分。
Figure 4: Implicit Grant Flow
图4：隐式赠款流
The flow illustrated in Figure 4 includes the following steps:
图4所示的流程包括以下步骤：
(A) The client initiates the flow by directing the resource owner's user-agent to the authorization endpoint. The client includes its client identifier, requested scope, local state, and a redirection URI to which the authorization server will send the user-agent back once access is granted (or denied).
（A） 客户端通过将资源所有者的用户代理定向到授权端点来启动流。客户机包括其客户机标识符、请求的作用域、本地状态和重定向URI，一旦授予（或拒绝）访问权限，授权服务器将向其发回用户代理。
(B) The authorization server authenticates the resource owner (via the user-agent) and establishes whether the resource owner grants or denies the client's access request.
（B） 授权服务器（通过用户代理）验证资源所有者，并确定资源所有者是批准还是拒绝客户端的访问请求。
(C) Assuming the resource owner grants access, the authorization server redirects the user-agent back to the client using the redirection URI provided earlier. The redirection URI includes the access token in the URI fragment.
（C） 假设资源所有者授予访问权限，授权服务器使用前面提供的重定向URI将用户代理重定向回客户端。重定向URI在URI片段中包含访问令牌。
(D) The user-agent follows the redirection instructions by making a request to the web-hosted client resource (which does not include the fragment per [RFC2616]). The user-agent retains the fragment information locally.
（D） 用户代理通过向web承载的客户端资源发出请求（不包括[RFC2616]中的片段）来遵循重定向说明。用户代理在本地保留片段信息。
(E) The web-hosted client resource returns a web page (typically an HTML document with an embedded script) capable of accessing the full redirection URI including the fragment retained by the user-agent, and extracting the access token (and other parameters) contained in the fragment.
（E） web承载的客户端资源返回一个网页（通常是一个带有嵌入式脚本的HTML文档），该网页能够访问完整的重定向URI，包括用户代理保留的片段，并提取片段中包含的访问令牌（和其他参数）。
(F) The user-agent executes the script provided by the web-hosted client resource locally, which extracts the access token.
（F） 用户代理在本地执行web托管客户端资源提供的脚本，该脚本提取访问令牌。
(G) The user-agent passes the access token to the client.
（G） 用户代理将访问令牌传递给客户端。
See Sections 1.3.2 and 9 for background on using the implicit grant. See Sections 10.3 and 10.16 for important security considerations when using the implicit grant.
参见第1.3.2节和第9节了解使用隐式授权的背景。有关使用隐式授权时的重要安全注意事项，请参见第10.3节和第10.16节。
The client constructs the request URI by adding the following parameters to the query component of the authorization endpoint URI using the "application/x-www-form-urlencoded" format, per Appendix B:
根据附录B，客户机通过使用“application/x-www-form-urlencoded”格式向授权端点URI的查询组件添加以下参数来构造请求URI：
response_type REQUIRED. Value MUST be set to "token".
需要响应类型。值必须设置为“令牌”。
client_id REQUIRED. The client identifier as described in Section 2.2.
需要客户端id。第2.2节所述的客户标识符。
redirect_uri OPTIONAL. As described in Section 3.1.2.
重定向uri是可选的。如第3.1.2节所述。
scope OPTIONAL. The scope of the access request as described by Section 3.3.
范围可选。访问请求的范围如第3.3节所述。
state RECOMMENDED. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The parameter SHOULD be used for preventing cross-site request forgery as described in Section 10.12.
国家建议。客户端用于维护请求和回调之间的状态的不透明值。授权服务器在将用户代理重定向回客户端时包含此值。该参数应用于防止跨站点请求伪造，如第10.12节所述。
The client directs the resource owner to the constructed URI using an HTTP redirection response, or by other means available to it via the user-agent.
客户端使用HTTP重定向响应或通过用户代理提供的其他方式将资源所有者定向到构造的URI。
For example, the client directs the user-agent to make the following HTTP request using TLS (with extra line breaks for display purposes only):
例如，客户端指示用户代理使用TLS发出以下HTTP请求（额外的换行符仅用于显示目的）：
GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
The authorization server validates the request to ensure that all required parameters are present and valid. The authorization server MUST verify that the redirection URI to which it will redirect the access token matches a redirection URI registered by the client as described in Section 3.1.2.
授权服务器验证请求，以确保所有必需的参数都存在且有效。授权服务器必须验证其将访问令牌重定向到的重定向URI是否与客户端注册的重定向URI匹配，如第3.1.2节所述。
If the request is valid, the authorization server authenticates the resource owner and obtains an authorization decision (by asking the resource owner or by establishing approval via other means).
如果请求有效，则授权服务器验证资源所有者并获得授权决策（通过询问资源所有者或通过其他方式建立批准）。
When a decision is established, the authorization server directs the user-agent to the provided client redirection URI using an HTTP redirection response, or by other means available to it via the user-agent.
当确定决策时，授权服务器使用HTTP重定向响应或通过用户代理可用的其他方式将用户代理定向到提供的客户端重定向URI。
If the resource owner grants the access request, the authorization server issues an access token and delivers it to the client by adding the following parameters to the fragment component of the redirection URI using the "application/x-www-form-urlencoded" format, per Appendix B:
如果资源所有者授予访问请求，授权服务器将发出一个访问令牌，并通过使用“application/x-www-form-urlencoded”格式将以下参数添加到重定向URI的片段组件，按照附录B将其发送给客户端：
access_token REQUIRED. The access token issued by the authorization server.
需要访问\u令牌。授权服务器颁发的访问令牌。
token_type REQUIRED. The type of the token issued as described in Section 7.1. Value is case insensitive.
需要令牌类型。按照第7.1节所述发布的令牌类型。值不区分大小写。
expires_in RECOMMENDED. The lifetime in seconds of the access token. For example, the value "3600" denotes that the access token will expire in one hour from the time the response was generated. If omitted, the authorization server SHOULD provide the expiration time via other means or document the default value.
以推荐的方式过期。访问令牌的生存期（以秒为单位）。例如，值“3600”表示访问令牌将在生成响应后一小时内过期。如果省略，授权服务器应通过其他方式提供过期时间或记录默认值。
scope OPTIONAL, if identical to the scope requested by the client; otherwise, REQUIRED. The scope of the access token as described by Section 3.3.
范围可选，如果与客户要求的范围相同；否则，需要。访问令牌的范围如第3.3节所述。
state REQUIRED if the "state" parameter was present in the client authorization request. The exact value received from the client.
如果客户端授权请求中存在“state”参数，则需要state。从客户端收到的确切值。
The authorization server MUST NOT issue a refresh token.
授权服务器不得发出刷新令牌。
For example, the authorization server redirects the user-agent by sending the following HTTP response (with extra line breaks for display purposes only):
例如，授权服务器通过发送以下HTTP响应重定向用户代理（带有额外的换行符，仅用于显示）：
HTTP/1.1 302 Found
Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
&state=xyz&token_type=example&expires_in=3600
HTTP/1.1 302 Found
Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
&state=xyz&token_type=example&expires_in=3600
Developers should note that some user-agents do not support the inclusion of a fragment component in the HTTP "Location" response header field. Such clients will require using other methods for redirecting the client than a 3xx redirection response -- for example, returning an HTML page that includes a 'continue' button with an action linked to the redirection URI.
开发人员应该注意，一些用户代理不支持在HTTP“Location”响应头字段中包含片段组件。此类客户端将需要使用3xx重定向响应以外的其他方法重定向客户端——例如，返回包含“继续”按钮的HTML页面，其中包含链接到重定向URI的操作。
The client MUST ignore unrecognized response parameters. The access token string size is left undefined by this specification. The client should avoid making assumptions about value sizes. The authorization server SHOULD document the size of any value it issues.
客户端必须忽略无法识别的响应参数。本规范未定义访问令牌字符串大小。客户应避免对价值大小进行假设。授权服务器应记录其发出的任何值的大小。
If the request fails due to a missing, invalid, or mismatching redirection URI, or if the client identifier is missing or invalid, the authorization server SHOULD inform the resource owner of the error and MUST NOT automatically redirect the user-agent to the invalid redirection URI.
如果由于重定向URI丢失、无效或不匹配而导致请求失败，或者如果客户端标识符丢失或无效，则授权服务器应将错误通知资源所有者，并且不得自动将用户代理重定向到无效的重定向URI。
If the resource owner denies the access request or if the request fails for reasons other than a missing or invalid redirection URI, the authorization server informs the client by adding the following parameters to the fragment component of the redirection URI using the "application/x-www-form-urlencoded" format, per Appendix B:
如果资源所有者拒绝访问请求，或者如果请求因缺少或无效重定向URI以外的原因而失败，授权服务器将根据附录B，使用“application/x-www-form-urlencoded”格式向重定向URI的片段组件添加以下参数，从而通知客户机：
error REQUIRED. A single ASCII [USASCII] error code from the following:
错误要求。一个ASCII[USASCII]错误代码来自以下代码：
invalid_request The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed.
无效的_请求请求缺少必需的参数、包含无效的参数值、多次包含参数或格式不正确。
unauthorized_client The client is not authorized to request an access token using this method.
未授权的\u客户端客户端未授权客户端使用此方法请求访问令牌。
access_denied The resource owner or authorization server denied the request.
资源所有者或授权服务器拒绝了访问请求。
unsupported_response_type The authorization server does not support obtaining an access token using this method.
不支持的\u响应\u类型授权服务器不支持使用此方法获取访问令牌。
invalid_scope The requested scope is invalid, unknown, or malformed.
无效\u作用域请求的作用域无效、未知或格式不正确。
server_error The authorization server encountered an unexpected condition that prevented it from fulfilling the request. (This error code is needed because a 500 Internal Server Error HTTP status code cannot be returned to the client via an HTTP redirect.)
服务器\错误授权服务器遇到意外情况，无法满足请求。（需要此错误代码，因为无法通过HTTP重定向将500内部服务器错误HTTP状态代码返回给客户端。）
temporarily_unavailable The authorization server is currently unable to handle the request due to a temporary overloading or maintenance of the server. (This error code is needed because a 503 Service Unavailable HTTP status code cannot be returned to the client via an HTTP redirect.)
暂时不可用由于服务器临时过载或维护，授权服务器当前无法处理请求。（需要此错误代码，因为无法通过HTTP重定向将503服务不可用HTTP状态代码返回给客户端。）
Values for the "error" parameter MUST NOT include characters outside the set %x20-21 / %x23-5B / %x5D-7E.
“error”参数的值不得包含集合%x20-21/%x23-5B/%x5D-7E之外的字符。
error_description OPTIONAL. Human-readable ASCII [USASCII] text providing additional information, used to assist the client developer in understanding the error that occurred. Values for the "error_description" parameter MUST NOT include characters outside the set %x20-21 / %x23-5B / %x5D-7E.
错误描述是可选的。人类可读的ASCII[USASCI]文本，提供附加信息，用于帮助客户机开发人员理解发生的错误。“error_description”参数的值不得包含集合%x20-21/%x23-5B/%x5D-7E之外的字符。
error_uri OPTIONAL. A URI identifying a human-readable web page with information about the error, used to provide the client developer with additional information about the error. Values for the "error_uri" parameter MUST conform to the URI-reference syntax and thus MUST NOT include characters outside the set %x21 / %x23-5B / %x5D-7E.
错误\u uri可选。一种URI，用错误信息标识人类可读的网页，用于向客户端开发人员提供有关错误的附加信息。“error_uri”参数的值必须符合uri引用语法，因此不能包含集合%x21/%x23-5B/%x5D-7E之外的字符。
state REQUIRED if a "state" parameter was present in the client authorization request. The exact value received from the client.
如果客户端授权请求中存在“状态”参数，则需要状态。从客户端收到的确切值。
For example, the authorization server redirects the user-agent by sending the following HTTP response:
例如，授权服务器通过发送以下HTTP响应重定向用户代理：
HTTP/1.1 302 Found
Location: https://client.example.com/cb#error=access_denied&state=xyz
HTTP/1.1 302 Found
Location: https://client.example.com/cb#error=access_denied&state=xyz
The resource owner password credentials grant type is suitable in cases where the resource owner has a trust relationship with the client, such as the device operating system or a highly privileged
资源所有者密码凭据授予类型适用于资源所有者与客户端具有信任关系的情况，例如设备操作系统或高特权服务器
application. The authorization server should take special care when enabling this grant type and only allow it when other flows are not viable.
应用授权服务器在启用此授权类型时应特别小心，并且仅在其他流不可行时才允许它。
This grant type is suitable for clients capable of obtaining the resource owner's credentials (username and password, typically using an interactive form). It is also used to migrate existing clients using direct authentication schemes such as HTTP Basic or Digest authentication to OAuth by converting the stored credentials to an access token.
此授权类型适用于能够获取资源所有者凭据（用户名和密码，通常使用交互式表单）的客户端。它还用于通过将存储的凭据转换为访问令牌，使用直接身份验证方案（如HTTP Basic或摘要身份验证）将现有客户端迁移到OAuth。
+----------+
| Resource |
| Owner |
| |
+----------+
v
| Resource Owner
(A) Password Credentials
|
v
+---------+ +---------------+
| |>--(B)---- Resource Owner ------->| |
| | Password Credentials | Authorization |
| Client | | Server |
| |<--(C)---- Access Token ---------<| |
| | (w/ Optional Refresh Token) | |
+---------+ +---------------+
+----------+
| Resource |
| Owner |
| |
+----------+
v
| Resource Owner
(A) Password Credentials
|
v
+---------+ +---------------+
| |>--(B)---- Resource Owner ------->| |
| | Password Credentials | Authorization |
| Client | | Server |
| |<--(C)---- Access Token ---------<| |
| | (w/ Optional Refresh Token) | |
+---------+ +---------------+
Figure 5: Resource Owner Password Credentials Flow
图5：资源所有者密码凭据流
The flow illustrated in Figure 5 includes the following steps:
图5所示的流程包括以下步骤：
(A) The resource owner provides the client with its username and password.
（A） 资源所有者向客户端提供其用户名和密码。
(B) The client requests an access token from the authorization server's token endpoint by including the credentials received from the resource owner. When making the request, the client authenticates with the authorization server.
（B） 客户端通过包括从资源所有者接收的凭据，从授权服务器的令牌端点请求访问令牌。发出请求时，客户机通过授权服务器进行身份验证。
(C) The authorization server authenticates the client and validates the resource owner credentials, and if valid, issues an access token.
（C） 授权服务器验证客户端并验证资源所有者凭据，如果有效，则发出访问令牌。
The method through which the client obtains the resource owner credentials is beyond the scope of this specification. The client MUST discard the credentials once an access token has been obtained.
客户端获取资源所有者凭据的方法超出了本规范的范围。一旦获得访问令牌，客户端必须丢弃凭据。
The client makes a request to the token endpoint by adding the following parameters using the "application/x-www-form-urlencoded" format per Appendix B with a character encoding of UTF-8 in the HTTP request entity-body:
客户端通过使用附录B中的“application/x-www-form-urlencoded”格式添加以下参数向令牌端点发出请求，HTTP请求实体正文中的字符编码为UTF-8：
grant_type REQUIRED. Value MUST be set to "password".
授权类型是必需的。值必须设置为“密码”。
username REQUIRED. The resource owner username.
需要用户名。资源所有者用户名。
password REQUIRED. The resource owner password.
需要密码。资源所有者密码。
scope OPTIONAL. The scope of the access request as described by Section 3.3.
范围可选。访问请求的范围如第3.3节所述。
If the client type is confidential or 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.
如果客户机类型是机密的，或者客户机被颁发了客户机凭据（或分配了其他身份验证要求），则客户机必须按照第3.2.1节中的说明向授权服务器进行身份验证。
For example, the client makes the following HTTP request using transport-layer security (with extra line breaks for display purposes only):
例如，客户端使用传输层安全性发出以下HTTP请求（额外的换行符仅用于显示目的）：
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=password&username=johndoe&password=A3ddj3w
grant_type=password&username=johndoe&password=A3ddj3w
The authorization server MUST:
授权服务器必须：
o require client authentication for confidential clients or for any client that was issued client credentials (or with other authentication requirements),
o 要求对机密客户或任何获得客户凭证的客户进行客户身份验证（或符合其他身份验证要求），
o authenticate the client if client authentication is included, and
o 如果包括客户端身份验证，则对客户端进行身份验证，以及
o validate the resource owner password credentials using its existing password validation algorithm.
o 使用现有密码验证算法验证资源所有者密码凭据。
Since this access token request utilizes the resource owner's password, the authorization server MUST protect the endpoint against brute force attacks (e.g., using rate-limitation or generating alerts).
由于此访问令牌请求使用资源所有者的密码，授权服务器必须保护端点免受暴力攻击（例如，使用速率限制或生成警报）。
If the access token request is valid and authorized, the authorization server issues an access token and optional refresh token as described in Section 5.1. If the request failed client authentication or is invalid, the authorization server returns an error response as described in Section 5.2.
如果访问令牌请求有效且已授权，则授权服务器将发出访问令牌和可选刷新令牌，如第5.1节所述。如果请求未通过客户端身份验证或无效，授权服务器将返回错误响应，如第5.2节所述。
An example successful response:
成功响应的一个示例：
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
The client can request an access token using only its client credentials (or other supported means of authentication) when the client is requesting access to the protected resources under its control, or those of another resource owner that have been previously arranged with the authorization server (the method of which is beyond the scope of this specification).
当客户端请求访问其控制下的受保护资源或先前与授权服务器一起安排的其他资源所有者的资源时，客户端可以仅使用其客户端凭据（或其他支持的身份验证方式）请求访问令牌（其方法超出本规范的范围）。
The client credentials grant type MUST only be used by confidential clients.
客户端凭据授予类型只能由机密客户端使用。
+---------+ +---------------+
| | | |
| |>--(A)- Client Authentication --->| Authorization |
| Client | | Server |
| |<--(B)---- Access Token ---------<| |
| | | |
+---------+ +---------------+
+---------+ +---------------+
| | | |
| |>--(A)- Client Authentication --->| Authorization |
| Client | | Server |
| |<--(B)---- Access Token ---------<| |
| | | |
+---------+ +---------------+
Figure 6: Client Credentials Flow
图6：客户端凭据流
The flow illustrated in Figure 6 includes the following steps:
图6所示的流程包括以下步骤：
(A) The client authenticates with the authorization server and requests an access token from the token endpoint.
（A） 客户端通过授权服务器进行身份验证，并从令牌端点请求访问令牌。
(B) The authorization server authenticates the client, and if valid, issues an access token.
（B） 授权服务器对客户端进行身份验证，如果有效，则发出访问令牌。
Since the client authentication is used as the authorization grant, no additional authorization request is needed.
由于客户端身份验证用作授权授予，因此不需要额外的授权请求。
The client makes a request to the token endpoint by adding the following parameters using the "application/x-www-form-urlencoded" format per Appendix B with a character encoding of UTF-8 in the HTTP request entity-body:
客户端通过使用附录B中的“application/x-www-form-urlencoded”格式添加以下参数向令牌端点发出请求，HTTP请求实体正文中的字符编码为UTF-8：
grant_type REQUIRED. Value MUST be set to "client_credentials".
授权类型是必需的。值必须设置为“客户端凭据”。
scope OPTIONAL. The scope of the access request as described by Section 3.3.
范围可选。访问请求的范围如第3.3节所述。
The client MUST authenticate with the authorization server as described in Section 3.2.1.
如第3.2.1节所述，客户端必须通过授权服务器进行身份验证。
For example, the client makes the following HTTP request using transport-layer security (with extra line breaks for display purposes only):
例如，客户端使用传输层安全性发出以下HTTP请求（额外的换行符仅用于显示目的）：
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
授予\类型=客户端\凭据
The authorization server MUST authenticate the client.
授权服务器必须对客户端进行身份验证。
If the access token request is valid and authorized, the authorization server issues an access token as described in Section 5.1. A refresh token SHOULD NOT be included. If the request failed client authentication or is invalid, the authorization server returns an error response as described in Section 5.2.
如果访问令牌请求有效且已授权，则授权服务器将按照第5.1节所述发布访问令牌。不应包括刷新令牌。如果请求未通过客户端身份验证或无效，授权服务器将返回错误响应，如第5.2节所述。
An example successful response:
成功响应的一个示例：
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"example_parameter":"example_value"
}
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"example_parameter":"example_value"
}
The client uses an extension grant type by specifying the grant type using an absolute URI (defined by the authorization server) as the value of the "grant_type" parameter of the token endpoint, and by adding any additional parameters necessary.
客户端通过使用绝对URI（由授权服务器定义）指定授权类型作为令牌端点的“grant_type”参数的值，并通过添加任何必要的附加参数，来使用扩展授权类型。
For example, to request an access token using a Security Assertion Markup Language (SAML) 2.0 assertion grant type as defined by [OAuth-SAML2], the client could make the following HTTP request using TLS (with extra line breaks for display purposes only):
例如，要使用[OAuth-SAML2]定义的安全断言标记语言（SAML）2.0断言授予类型请求访问令牌，客户端可以使用TLS发出以下HTTP请求（额外的换行符仅用于显示目的）：
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%3Asaml2- bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU [...omitted for brevity...]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-
授权类型=urn%3IETF%3参数%3OAuth%3授权类型%3SAML2-承载和断言=PEFZC2VYDGLVIBJC3N1ZULUC3RHBNQ9IJIWMTETMDU[…为简洁起见省略…]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24-
If the access token request is valid and authorized, the authorization server issues an access token and optional refresh token as described in Section 5.1. If the request failed client authentication or is invalid, the authorization server returns an error response as described in Section 5.2.
如果访问令牌请求有效且已授权，则授权服务器将发出访问令牌和可选刷新令牌，如第5.1节所述。如果请求未通过客户端身份验证或无效，授权服务器将返回错误响应，如第5.2节所述。
If the access token request is valid and authorized, the authorization server issues an access token and optional refresh token as described in Section 5.1. If the request failed client authentication or is invalid, the authorization server returns an error response as described in Section 5.2.
如果访问令牌请求有效且已授权，则授权服务器将发出访问令牌和可选刷新令牌，如第5.1节所述。如果请求未通过客户端身份验证或无效，授权服务器将返回错误响应，如第5.2节所述。
The authorization server issues an access token and optional refresh token, and constructs the response by adding the following parameters to the entity-body of the HTTP response with a 200 (OK) status code:
授权服务器发出访问令牌和可选刷新令牌，并通过向HTTP响应的实体体添加以下参数（状态代码为200（OK））来构造响应：
access_token REQUIRED. The access token issued by the authorization server.
需要访问\u令牌。授权服务器颁发的访问令牌。
token_type REQUIRED. The type of the token issued as described in Section 7.1. Value is case insensitive.
需要令牌类型。按照第7.1节所述发布的令牌类型。值不区分大小写。
expires_in RECOMMENDED. The lifetime in seconds of the access token. For example, the value "3600" denotes that the access token will expire in one hour from the time the response was generated. If omitted, the authorization server SHOULD provide the expiration time via other means or document the default value.
以推荐的方式过期。访问令牌的生存期（以秒为单位）。例如，值“3600”表示访问令牌将在生成响应后一小时内过期。如果省略，授权服务器应通过其他方式提供过期时间或记录默认值。
refresh_token OPTIONAL. The refresh token, which can be used to obtain new access tokens using the same authorization grant as described in Section 6.
刷新令牌（可选）。刷新令牌，可用于使用第6节所述的相同授权授予获取新的访问令牌。
scope OPTIONAL, if identical to the scope requested by the client; otherwise, REQUIRED. The scope of the access token as described by Section 3.3.
范围可选，如果与客户要求的范围相同；否则，需要。访问令牌的范围如第3.3节所述。
The parameters are included in the entity-body of the HTTP response using the "application/json" media type as defined by [RFC4627]. The parameters are serialized into a JavaScript Object Notation (JSON) structure by adding each parameter at the highest structure level. Parameter names and string values are included as JSON strings. Numerical values are included as JSON numbers. The order of parameters does not matter and can vary.
这些参数使用[RFC4627]定义的“application/json”媒体类型包含在HTTP响应的实体体中。通过在最高结构级别添加每个参数，将参数序列化为JavaScript对象表示法（JSON）结构。参数名和字符串值作为JSON字符串包含。数值包含为JSON编号。参数的顺序无关紧要，可以改变。
The authorization server MUST include the HTTP "Cache-Control" response header field [RFC2616] with a value of "no-store" in any response containing tokens, credentials, or other sensitive information, as well as the "Pragma" response header field [RFC2616] with a value of "no-cache".
授权服务器必须在包含令牌、凭据或其他敏感信息的任何响应中包含值为“no store”的HTTP“Cache Control”响应头字段[RFC2616]，以及值为“no Cache”的“Pragma”响应头字段[RFC2616]。
For example:
例如：
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
The client MUST ignore unrecognized value names in the response. The sizes of tokens and other values received from the authorization server are left undefined. The client should avoid making assumptions about value sizes. The authorization server SHOULD document the size of any value it issues.
客户端必须忽略响应中无法识别的值名称。从授权服务器接收的令牌和其他值的大小未定义。客户应避免对价值大小进行假设。授权服务器应记录其发出的任何值的大小。
The authorization server responds with an HTTP 400 (Bad Request) status code (unless specified otherwise) and includes the following parameters with the response:
授权服务器使用HTTP 400（错误请求）状态代码进行响应（除非另有规定），并在响应中包含以下参数：
error REQUIRED. A single ASCII [USASCII] error code from the following:
错误要求。一个ASCII[USASCII]错误代码来自以下代码：
invalid_request The request is missing a required parameter, includes an unsupported parameter value (other than grant type), repeats a parameter, includes multiple credentials, utilizes more than one mechanism for authenticating the client, or is otherwise malformed.
无效的\u请求请求缺少必需的参数、包含不受支持的参数值（授权类型除外）、重复参数、包含多个凭据、使用多个机制对客户端进行身份验证，或者格式不正确。
invalid_client Client authentication failed (e.g., unknown client, no client authentication included, or unsupported authentication method). The authorization server MAY return an HTTP 401 (Unauthorized) status code to indicate which HTTP authentication schemes are supported. If the client attempted to authenticate via the "Authorization" request header field, the authorization server MUST respond with an HTTP 401 (Unauthorized) status code and include the "WWW-Authenticate" response header field matching the authentication scheme used by the client.
无效的_客户端身份验证失败（例如，未知客户端、未包含客户端身份验证或不支持的身份验证方法）。授权服务器可以返回HTTP 401（未授权）状态代码，以指示支持哪些HTTP认证方案。如果客户端试图通过“Authorization”请求标头字段进行身份验证，则授权服务器必须使用HTTP 401（未经授权）状态代码进行响应，并包括与客户端使用的身份验证方案匹配的“WWW authenticate”响应标头字段。
invalid_grant The provided authorization grant (e.g., authorization code, resource owner credentials) or refresh token is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client.
无效\u授予提供的授权授予（例如，授权代码、资源所有者凭据）或刷新令牌无效、过期、已吊销、与授权请求中使用的重定向URI不匹配，或已颁发给其他客户端。
unauthorized_client The authenticated client is not authorized to use this authorization grant type.
未经授权的\u客户端已验证的客户端无权使用此授权授予类型。
unsupported_grant_type The authorization grant type is not supported by the authorization server.
不支持的授权类型授权服务器不支持该授权类型。
invalid_scope The requested scope is invalid, unknown, malformed, or exceeds the scope granted by the resource owner.
无效\u范围请求的范围无效、未知、格式错误或超出了资源所有者授予的范围。
Values for the "error" parameter MUST NOT include characters outside the set %x20-21 / %x23-5B / %x5D-7E.
“error”参数的值不得包含集合%x20-21/%x23-5B/%x5D-7E之外的字符。
error_description OPTIONAL. Human-readable ASCII [USASCII] text providing additional information, used to assist the client developer in understanding the error that occurred. Values for the "error_description" parameter MUST NOT include characters outside the set %x20-21 / %x23-5B / %x5D-7E.
错误描述是可选的。人类可读的ASCII[USASCI]文本，提供附加信息，用于帮助客户机开发人员理解发生的错误。“error_description”参数的值不得包含集合%x20-21/%x23-5B/%x5D-7E之外的字符。
error_uri OPTIONAL. A URI identifying a human-readable web page with information about the error, used to provide the client developer with additional information about the error. Values for the "error_uri" parameter MUST conform to the URI-reference syntax and thus MUST NOT include characters outside the set %x21 / %x23-5B / %x5D-7E.
错误\u uri可选。一种URI，用错误信息标识人类可读的网页，用于向客户端开发人员提供有关错误的附加信息。“error_uri”参数的值必须符合uri引用语法，因此不能包含集合%x21/%x23-5B/%x5D-7E之外的字符。
The parameters are included in the entity-body of the HTTP response using the "application/json" media type as defined by [RFC4627]. The parameters are serialized into a JSON structure by adding each parameter at the highest structure level. Parameter names and string values are included as JSON strings. Numerical values are included as JSON numbers. The order of parameters does not matter and can vary.
这些参数使用[RFC4627]定义的“application/json”媒体类型包含在HTTP响应的实体体中。通过在最高结构级别添加每个参数，将参数序列化为JSON结构。参数名和字符串值作为JSON字符串包含。数值包含为JSON编号。参数的顺序无关紧要，可以改变。
For example:
例如：
HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"error":"invalid_request"
}
{
"error":"invalid_request"
}
If the authorization server issued a refresh token to the client, the client makes a refresh request to the token endpoint by adding the following parameters using the "application/x-www-form-urlencoded" format per Appendix B with a character encoding of UTF-8 in the HTTP request entity-body:
如果授权服务器向客户端发出刷新令牌，则客户端通过使用附录B中的“application/x-www-form-urlencoded”格式（HTTP请求实体体中的字符编码为UTF-8）添加以下参数，向令牌端点发出刷新请求：
grant_type REQUIRED. Value MUST be set to "refresh_token".
授权类型是必需的。值必须设置为“刷新令牌”。
refresh_token REQUIRED. The refresh token issued to the client.
需要刷新\u令牌。颁发给客户端的刷新令牌。
scope OPTIONAL. The scope of the access request as described by Section 3.3. The requested scope MUST NOT include any scope not originally granted by the resource owner, and if omitted is treated as equal to the scope originally granted by the resource owner.
范围可选。访问请求的范围如第3.3节所述。请求的范围不得包括任何最初未由资源所有者授予的范围，如果省略，则视为与最初由资源所有者授予的范围相等。
Because refresh tokens are typically long-lasting credentials used to request additional access tokens, the refresh token is bound to the client to which it was issued. If the client type is confidential or 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.
由于刷新令牌通常是用于请求其他访问令牌的持久凭据，因此刷新令牌绑定到向其发出刷新令牌的客户端。如果客户机类型是机密的，或者客户机被颁发了客户机凭据（或分配了其他身份验证要求），则客户机必须按照第3.2.1节中的说明向授权服务器进行身份验证。
For example, the client makes the following HTTP request using transport-layer security (with extra line breaks for display purposes only):
例如，客户端使用传输层安全性发出以下HTTP请求（额外的换行符仅用于显示目的）：
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
授权类型=刷新令牌&刷新令牌=tGzv3JOkF0XG5Qx2TlKWIA
The authorization server MUST:
授权服务器必须：
o require client authentication for confidential clients or for any client that was issued client credentials (or with other authentication requirements),
o 要求对机密客户或任何获得客户凭证的客户进行客户身份验证（或符合其他身份验证要求），
o authenticate the client if client authentication is included and ensure that the refresh token was issued to the authenticated client, and
o 如果包括客户端身份验证，则对客户端进行身份验证，并确保已将刷新令牌颁发给经过身份验证的客户端，以及
o validate the refresh token.
o 验证刷新令牌。
If valid and authorized, the authorization server issues an access token as described in Section 5.1. If the request failed verification or is invalid, the authorization server returns an error response as described in Section 5.2.
如果有效且经过授权，授权服务器将按照第5.1节所述发布访问令牌。如果请求验证失败或无效，授权服务器将返回错误响应，如第5.2节所述。
The authorization server MAY issue a new refresh token, in which case the client MUST discard the old refresh token and replace it with the new refresh token. The authorization server MAY revoke the old refresh token after issuing a new refresh token to the client. If a new refresh token is issued, the refresh token scope MUST be identical to that of the refresh token included by the client in the request.
授权服务器可以发出新的刷新令牌，在这种情况下，客户端必须丢弃旧的刷新令牌，并用新的刷新令牌替换它。授权服务器可以在向客户端发出新的刷新令牌之后撤销旧的刷新令牌。如果发出新的刷新令牌，则刷新令牌范围必须与客户端在请求中包含的刷新令牌范围相同。
The client accesses protected resources by presenting the access token to the resource server. The resource server MUST validate the access token and ensure that it has not expired and that its scope covers the requested resource. The methods used by the resource server to validate the access token (as well as any error responses) are beyond the scope of this specification but generally involve an interaction or coordination between the resource server and the authorization server.
客户端通过向资源服务器提供访问令牌来访问受保护的资源。资源服务器必须验证访问令牌，并确保其未过期，并且其作用域覆盖请求的资源。资源服务器用于验证访问令牌（以及任何错误响应）的方法超出了本规范的范围，但通常涉及资源服务器和授权服务器之间的交互或协调。
The method in which the client utilizes the access token to authenticate with the resource server depends on the type of access token issued by the authorization server. Typically, it involves using the HTTP "Authorization" request header field [RFC2617] with an authentication scheme defined by the specification of the access token type used, such as [RFC6750].
客户端使用访问令牌向资源服务器进行身份验证的方法取决于授权服务器颁发的访问令牌的类型。通常，它涉及使用HTTP“Authorization”请求头字段[RFC2617]和由所用访问令牌类型的规范定义的身份验证方案，例如[RFC6750]。
The access token type provides the client with the information required to successfully utilize the access token to make a protected resource request (along with type-specific attributes). The client MUST NOT use an access token if it does not understand the token type.
访问令牌类型为客户端提供成功利用访问令牌发出受保护资源请求所需的信息（以及特定于类型的属性）。如果客户端不了解令牌类型，则不能使用访问令牌。
For example, the "bearer" token type defined in [RFC6750] is utilized by simply including the access token string in the request:
例如，[RFC6750]中定义的“承载者”令牌类型仅通过在请求中包含访问令牌字符串来使用：
GET /resource/1 HTTP/1.1
Host: example.com
Authorization: Bearer mF_9.B5f-4.1JqM
GET /resource/1 HTTP/1.1
Host: example.com
Authorization: Bearer mF_9.B5f-4.1JqM
while the "mac" token type defined in [OAuth-HTTP-MAC] is utilized by issuing a Message Authentication Code (MAC) key together with the access token that is used to sign certain components of the HTTP requests:
虽然[OAuth HTTP mac]中定义的“mac”令牌类型通过发布消息认证码（mac）密钥以及用于对HTTP请求的某些组件进行签名的访问令牌来使用：
GET /resource/1 HTTP/1.1
Host: example.com
Authorization: MAC id="h480djs93hd8",
nonce="274312:dj83hs9s",
mac="kDZvddkndxvhGRXZhvuDjEWhGeE="
GET /resource/1 HTTP/1.1
Host: example.com
Authorization: MAC id="h480djs93hd8",
nonce="274312:dj83hs9s",
mac="kDZvddkndxvhGRXZhvuDjEWhGeE="
The above examples are provided for illustration purposes only. Developers are advised to consult the [RFC6750] and [OAuth-HTTP-MAC] specifications before use.
以上示例仅用于说明目的。建议开发者在使用前参考[RFC6750]和[OAuth HTTP MAC]规范。
Each access token type definition specifies the additional attributes (if any) sent to the client together with the "access_token" response parameter. It also defines the HTTP authentication method used to include the access token when making a protected resource request.
每个访问令牌类型定义指定与“访问令牌”响应参数一起发送到客户端的附加属性（如果有）。它还定义了在发出受保护的资源请求时用于包含访问令牌的HTTP身份验证方法。
If a resource access request fails, the resource server SHOULD inform the client of the error. While the specifics of such error responses are beyond the scope of this specification, this document establishes a common registry in Section 11.4 for error values to be shared among OAuth token authentication schemes.
如果资源访问请求失败，资源服务器应将错误通知客户端。虽然此类错误响应的细节超出了本规范的范围，但本文档在第11.4节中为OAuth令牌身份验证方案之间共享的错误值建立了一个公共注册表。
New authentication schemes designed primarily for OAuth token authentication SHOULD define a mechanism for providing an error status code to the client, in which the error values allowed are registered in the error registry established by this specification.
主要为OAuth令牌身份验证设计的新身份验证方案应定义一种机制，用于向客户端提供错误状态代码，其中允许的错误值在本规范建立的错误注册表中注册。
Such schemes MAY limit the set of valid error codes to a subset of the registered values. If the error code is returned using a named parameter, the parameter name SHOULD be "error".
此类方案可将有效错误代码集限制为注册值的子集。如果使用命名参数返回错误代码，则参数名称应为“error”。
Other schemes capable of being used for OAuth token authentication, but not primarily designed for that purpose, MAY bind their error values to the registry in the same manner.
其他能够用于OAuth令牌身份验证的方案，但主要不是为此目的而设计的，可以以相同的方式将其错误值绑定到注册表。
New authentication schemes MAY choose to also specify the use of the "error_description" and "error_uri" parameters to return error information in a manner parallel to their usage in this specification.
新的认证方案还可以选择指定“error\u description”和“error\u uri”参数的使用，以与其在本规范中的使用平行的方式返回错误信息。
Access token types can be defined in one of two ways: registered in the Access Token Types registry (following the procedures in Section 11.1), or by using a unique absolute URI as its name.
访问令牌类型可以通过以下两种方式之一定义：在访问令牌类型注册表中注册（遵循第11.1节中的过程），或使用唯一的绝对URI作为其名称。
Types utilizing a URI name SHOULD be limited to vendor-specific implementations that are not commonly applicable, and are specific to the implementation details of the resource server where they are used.
使用URI名称的类型应限于通常不适用的特定于供应商的实现，并且特定于使用它们的资源服务器的实现细节。
All other types MUST be registered. Type names MUST conform to the type-name ABNF. If the type definition includes a new HTTP authentication scheme, the type name SHOULD be identical to the HTTP authentication scheme name (as defined by [RFC2617]). The token type "example" is reserved for use in examples.
所有其他类型都必须注册。类型名称必须与类型名称ABNF一致。如果类型定义包括新的HTTP身份验证方案，则类型名称应与HTTP身份验证方案名称相同（如[RFC2617]所定义）。标记类型“example”保留用于示例中。
type-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
type-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
New request or response parameters for use with the authorization endpoint or the token endpoint are defined and registered in the OAuth Parameters registry following the procedure in Section 11.2.
按照第11.2节中的过程，在OAuth参数注册表中定义并注册用于授权端点或令牌端点的新请求或响应参数。
Parameter names MUST conform to the param-name ABNF, and parameter values syntax MUST be well-defined (e.g., using ABNF, or a reference to the syntax of an existing parameter).
参数名称必须符合参数名称ABNF，参数值语法必须定义良好（例如，使用ABNF或引用现有参数的语法）。
param-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
param-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
Unregistered vendor-specific parameter extensions that are not commonly applicable and that are specific to the implementation details of the authorization server where they are used SHOULD utilize a vendor-specific prefix that is not likely to conflict with other registered values (e.g., begin with 'companyname_').
未注册的特定于供应商的参数扩展通常不适用，并且特定于使用它们的授权服务器的实现细节，应使用不可能与其他注册值冲突的特定于供应商的前缀（例如，以“companyname_389;”开头）。
New authorization grant types can be defined by assigning them a unique absolute URI for use with the "grant_type" parameter. If the extension grant type requires additional token endpoint parameters, they MUST be registered in the OAuth Parameters registry as described by Section 11.2.
新的授权授予类型可以通过为它们分配一个唯一的绝对URI来定义，以便与“grant_type”参数一起使用。如果扩展授权类型需要额外的令牌端点参数，则必须按照第11.2节所述在OAuth参数注册表中注册这些参数。
New response types for use with the authorization endpoint are defined and registered in the Authorization Endpoint Response Types registry following the procedure in Section 11.3. Response type names MUST conform to the response-type ABNF.
按照第11.3节中的过程，在授权端点响应类型注册表中定义并注册用于授权端点的新响应类型。响应类型名称必须符合响应类型ABNF。
response-type = response-name *( SP response-name )
response-name = 1*response-char
response-char = "_" / DIGIT / ALPHA
response-type = response-name *( SP response-name )
response-name = 1*response-char
response-char = "_" / DIGIT / ALPHA
If a response type contains one or more space characters (%x20), it is compared as a space-delimited list of values in which the order of values does not matter. Only one order of values can be registered, which covers all other arrangements of the same set of values.
如果响应类型包含一个或多个空格字符（%x20），则会将其作为以空格分隔的值列表进行比较，其中值的顺序无关紧要。只能注册一个值顺序，这涵盖了同一组值的所有其他排列。
For example, the response type "token code" is left undefined by this specification. However, an extension can define and register the "token code" response type. Once registered, the same combination cannot be registered as "code token", but both values can be used to denote the same response type.
例如，本规范未定义响应类型“令牌代码”。但是，扩展可以定义并注册“令牌代码”响应类型。一旦注册，相同的组合就不能注册为“代码令牌”，但这两个值都可以用来表示相同的响应类型。
In cases where protocol extensions (i.e., access token types, extension parameters, or extension grant types) require additional error codes to be used with the authorization code grant error response (Section 4.1.2.1), the implicit grant error response (Section 4.2.2.1), the token error response (Section 5.2), or the resource access error response (Section 7.2), such error codes MAY be defined.
如果协议扩展（即访问令牌类型、扩展参数或扩展授予类型）需要额外的错误代码与授权码授予错误响应（第4.1.2.1节）、隐式授予错误响应（第4.2.2.1节）、令牌错误响应（第5.2节）一起使用，或资源访问错误响应（第7.2节），可定义此类错误代码。
Extension error codes MUST be registered (following the procedures in Section 11.4) if the extension they are used in conjunction with is a registered access token type, a registered endpoint parameter, or an extension grant type. Error codes used with unregistered extensions MAY be registered.
如果与扩展一起使用的扩展是已注册的访问令牌类型、已注册的端点参数或扩展授予类型，则必须注册扩展错误代码（按照第11.4节中的过程）。与未注册的扩展名一起使用的错误代码可能已注册。
Error codes MUST conform to the error ABNF and SHOULD be prefixed by an identifying name when possible. For example, an error identifying an invalid value set to the extension parameter "example" SHOULD be named "example_invalid".
错误代码必须符合错误ABNF，并应尽可能以识别名称作为前缀。例如，识别为扩展参数“example”设置的无效值的错误应命名为“example\u invalid”。
error = 1*error-char
error-char = %x20-21 / %x23-5B / %x5D-7E
error = 1*error-char
error-char = %x20-21 / %x23-5B / %x5D-7E
Native applications are clients installed and executed on the device used by the resource owner (i.e., desktop application, native mobile application). Native applications require special consideration related to security, platform capabilities, and overall end-user experience.
本机应用程序是在资源所有者使用的设备（即桌面应用程序、本机移动应用程序）上安装和执行的客户端。本机应用程序需要特别考虑安全性、平台功能和总体最终用户体验。
The authorization endpoint requires interaction between the client and the resource owner's user-agent. Native applications can invoke an external user-agent or embed a user-agent within the application. For example:
授权端点需要客户端和资源所有者的用户代理之间的交互。本机应用程序可以调用外部用户代理或在应用程序中嵌入用户代理。例如：
o External user-agent - the native application can capture the response from the authorization server using a redirection URI with a scheme registered with the operating system to invoke the client as the handler, manual copy-and-paste of the credentials, running a local web server, installing a user-agent extension, or by providing a redirection URI identifying a server-hosted resource under the client's control, which in turn makes the response available to the native application.
o 外部用户代理-本机应用程序可以使用重定向URI捕获来自授权服务器的响应，重定向URI具有在操作系统中注册的方案，以调用客户端作为处理程序，手动复制和粘贴凭据，运行本地web服务器，安装用户代理扩展，或者通过提供一个重定向URI来标识客户端控制下的服务器托管资源，从而使响应对本机应用程序可用。
o Embedded user-agent - the native application obtains the response by directly communicating with the embedded user-agent by monitoring state changes emitted during the resource load, or accessing the user-agent's cookies storage.
o 嵌入式用户代理—本机应用程序通过监视资源加载期间发出的状态更改或访问用户代理的Cookie存储，直接与嵌入式用户代理通信，从而获得响应。
When choosing between an external or embedded user-agent, developers should consider the following:
当在外部或嵌入式用户代理之间进行选择时，开发人员应考虑以下事项：
o An external user-agent may improve completion rate, as the resource owner may already have an active session with the authorization server, removing the need to re-authenticate. It provides a familiar end-user experience and functionality. The
o 外部用户代理可以提高完成率，因为资源所有者可能已经与授权服务器有一个活动会话，无需重新验证。它提供了熟悉的最终用户体验和功能。这个
resource owner may also rely on user-agent features or extensions to assist with authentication (e.g., password manager, 2-factor device reader).
资源所有者还可以依赖用户代理功能或扩展来协助身份验证（例如，密码管理器、双因素设备读取器）。
o An embedded user-agent may offer improved usability, as it removes the need to switch context and open new windows.
o 嵌入式用户代理可以提供更好的可用性，因为它不需要切换上下文和打开新窗口。
o An embedded user-agent poses a security challenge because resource owners are authenticating in an unidentified window without access to the visual protections found in most external user-agents. An embedded user-agent educates end-users to trust unidentified requests for authentication (making phishing attacks easier to execute).
o 嵌入式用户代理带来了一个安全挑战，因为资源所有者在未识别的窗口中进行身份验证，而无法访问大多数外部用户代理中的可视保护。嵌入式用户代理教育最终用户信任身份验证的未识别请求（使钓鱼攻击更容易执行）。
When choosing between the implicit grant type and the authorization code grant type, the following should be considered:
在隐式授权类型和授权代码授权类型之间进行选择时，应考虑以下因素：
o Native applications that use the authorization code grant type SHOULD do so without using client credentials, due to the native application's inability to keep client credentials confidential.
o 使用授权码授权类型的本机应用程序不应使用客户端凭据，因为本机应用程序无法对客户端凭据保密。
o When using the implicit grant type flow, a refresh token is not returned, which requires repeating the authorization process once the access token expires.
o 使用隐式授权类型流时，不会返回刷新令牌，这需要在访问令牌过期后重复授权过程。
As a flexible and extensible framework, OAuth's security considerations depend on many factors. The following sections provide implementers with security guidelines focused on the three client profiles described in Section 2.1: web application, user-agent-based application, and native application.
作为一个灵活且可扩展的框架，OAuth的安全考虑取决于许多因素。以下各节为实现者提供了安全指南，重点介绍了第2.1节中描述的三种客户端配置文件：web应用程序、基于用户代理的应用程序和本机应用程序。
A comprehensive OAuth security model and analysis, as well as background for the protocol design, is provided by [OAuth-THREATMODEL].
[OAuth THREATMODEL]提供了全面的OAuth安全模型和分析，以及协议设计的背景。
The authorization server establishes client credentials with web application clients for the purpose of client authentication. The authorization server is encouraged to consider stronger client authentication means than a client password. Web application clients MUST ensure confidentiality of client passwords and other client credentials.
授权服务器与web应用程序客户端建立客户端凭据，以进行客户端身份验证。鼓励授权服务器考虑比客户端密码更强的客户端认证方式。Web应用程序客户端必须确保客户端密码和其他客户端凭据的机密性。
The authorization server MUST NOT issue client passwords or other client credentials to native application or user-agent-based application clients for the purpose of client authentication. The authorization server MAY issue a client password or other credentials for a specific installation of a native application client on a specific device.
授权服务器不得出于客户端身份验证的目的向本机应用程序或基于用户代理的应用程序客户端颁发客户端密码或其他客户端凭据。授权服务器可以为特定设备上本机应用程序客户端的特定安装颁发客户端密码或其他凭据。
When client authentication is not possible, the authorization server SHOULD employ other means to validate the client's identity -- for example, by requiring the registration of the client redirection URI or enlisting the resource owner to confirm identity. A valid redirection URI is not sufficient to verify the client's identity when asking for resource owner authorization but can be used to prevent delivering credentials to a counterfeit client after obtaining resource owner authorization.
当客户端身份验证不可能时，授权服务器应该使用其他方法来验证客户端的身份——例如，通过要求注册客户端重定向URI或登记资源所有者来确认身份。请求资源所有者授权时，有效的重定向URI不足以验证客户端的身份，但可用于防止在获得资源所有者授权后将凭据传递到伪造客户端。
The authorization server must consider the security implications of interacting with unauthenticated clients and take measures to limit the potential exposure of other credentials (e.g., refresh tokens) issued to such clients.
授权服务器必须考虑与未经认证的客户端交互的安全影响，并采取措施限制向此类客户端发出的其他凭据（例如刷新令牌）的潜在暴露。
A malicious client can impersonate another client and obtain access to protected resources if the impersonated client fails to, or is unable to, keep its client credentials confidential.
如果被模拟的客户端未能或无法对其客户端凭据保密，则恶意客户端可以模拟其他客户端并获得对受保护资源的访问权限。
The authorization server MUST authenticate the client whenever possible. If the authorization server cannot authenticate the client due to the client's nature, the authorization server MUST require the registration of any redirection URI used for receiving authorization responses and SHOULD utilize other means to protect resource owners from such potentially malicious clients. For example, the authorization server can engage the resource owner to assist in identifying the client and its origin.
授权服务器必须尽可能对客户端进行身份验证。如果由于客户端的性质，授权服务器无法对客户端进行身份验证，则授权服务器必须要求注册用于接收授权响应的任何重定向URI，并应利用其他手段保护资源所有者免受此类潜在恶意客户端的攻击。例如，授权服务器可以让资源所有者协助识别客户机及其来源。
The authorization server SHOULD enforce explicit resource owner authentication and provide the resource owner with information about the client and the requested authorization scope and lifetime. It is up to the resource owner to review the information in the context of the current client and to authorize or deny the request.
授权服务器应该强制执行显式的资源所有者身份验证，并向资源所有者提供有关客户端以及请求的授权范围和生存期的信息。由资源所有者在当前客户端的上下文中查看信息，并授权或拒绝请求。
The authorization server SHOULD NOT process repeated authorization requests automatically (without active resource owner interaction) without authenticating the client or relying on other measures to ensure that the repeated request comes from the original client and not an impersonator.
授权服务器不应自动处理重复的授权请求（无活动的资源所有者交互），而无需对客户端进行身份验证或依赖其他措施来确保重复的请求来自原始客户端而不是模拟者。
Access token credentials (as well as any confidential access token attributes) MUST be kept confidential in transit and storage, and only shared among the authorization server, the resource servers the access token is valid for, and the client to whom the access token is issued. Access token credentials MUST only be transmitted using TLS as described in Section 1.6 with server authentication as defined by [RFC2818].
访问令牌凭据（以及任何机密访问令牌属性）在传输和存储过程中必须保密，并且只能在授权服务器、访问令牌对其有效的资源服务器以及向其颁发访问令牌的客户端之间共享。访问令牌凭证只能使用第1.6节所述的TLS传输，并使用[RFC2818]定义的服务器身份验证。
When using the implicit grant type, the access token is transmitted in the URI fragment, which can expose it to unauthorized parties.
当使用隐式授权类型时，访问令牌在URI片段中传输，这会将其暴露给未经授权的方。
The authorization server MUST ensure that access tokens cannot be generated, modified, or guessed to produce valid access tokens by unauthorized parties.
授权服务器必须确保未经授权的各方不能生成、修改或猜测访问令牌以生成有效的访问令牌。
The client SHOULD request access tokens with the minimal scope necessary. The authorization server SHOULD take the client identity into account when choosing how to honor the requested scope and MAY issue an access token with less rights than requested.
客户机应该请求具有最小范围的访问令牌。授权服务器在选择如何执行请求的作用域时应考虑客户端标识，并且可能会发出权限小于请求权限的访问令牌。
This specification does not provide any methods for the resource server to ensure that an access token presented to it by a given client was issued to that client by the authorization server.
此规范不为资源服务器提供任何方法，以确保授权服务器将给定客户端提供给它的访问令牌颁发给该客户端。
Authorization servers MAY issue refresh tokens to web application clients and native application clients.
授权服务器可以向web应用程序客户端和本机应用程序客户端发出刷新令牌。
Refresh tokens MUST be kept confidential in transit and storage, and shared only among the authorization server and the client to whom the refresh tokens were issued. The authorization server MUST maintain the binding between a refresh token and the client to whom it was issued. Refresh tokens MUST only be transmitted using TLS as described in Section 1.6 with server authentication as defined by [RFC2818].
刷新令牌在传输和存储过程中必须保密，并且只能在授权服务器和向其颁发刷新令牌的客户端之间共享。授权服务器必须维护刷新令牌与向其发出该令牌的客户端之间的绑定。刷新令牌必须仅使用第1.6节所述的TLS传输，并使用[RFC2818]定义的服务器身份验证。
The authorization server MUST verify the binding between the refresh token and client identity whenever the client identity can be authenticated. When client authentication is not possible, the authorization server SHOULD deploy other means to detect refresh token abuse.
只要可以对客户端标识进行身份验证，授权服务器就必须验证刷新令牌和客户端标识之间的绑定。当无法进行客户端身份验证时，授权服务器应部署其他方法来检测刷新令牌滥用。
For example, the authorization server could employ refresh token rotation in which a new refresh token is issued with every access token refresh response. The previous refresh token is invalidated
例如，授权服务器可以采用刷新令牌轮换，其中每个访问令牌刷新响应都会发出一个新的刷新令牌。上一个刷新令牌无效
but retained by the authorization server. If a refresh token is compromised and subsequently used by both the attacker and the legitimate client, one of them will present an invalidated refresh token, which will inform the authorization server of the breach.
但由授权服务器保留。如果刷新令牌遭到破坏，并且随后被攻击者和合法客户端使用，其中一个将呈现无效的刷新令牌，这将通知授权服务器该违规行为。
The authorization server MUST ensure that refresh tokens cannot be generated, modified, or guessed to produce valid refresh tokens by unauthorized parties.
授权服务器必须确保未经授权的各方不能生成、修改或猜测刷新令牌以生成有效的刷新令牌。
The transmission of authorization codes SHOULD be made over a secure channel, and the client SHOULD require the use of TLS with its redirection URI if the URI identifies a network resource. Since authorization codes are transmitted via user-agent redirections, they could potentially be disclosed through user-agent history and HTTP referrer headers.
授权码的传输应通过安全通道进行，如果URI标识网络资源，则客户端应要求使用TLS及其重定向URI。由于授权码是通过用户代理重定向传输的，因此它们可能会通过用户代理历史记录和HTTP引用头被公开。
Authorization codes operate as plaintext bearer credentials, used to verify that the resource owner who granted authorization at the authorization server is the same resource owner returning to the client to complete the process. Therefore, if the client relies on the authorization code for its own resource owner authentication, the client redirection endpoint MUST require the use of TLS.
授权代码作为明文承载凭据运行，用于验证在授权服务器上授予授权的资源所有者是否是返回到客户端以完成该过程的同一资源所有者。因此，如果客户端依赖授权代码进行其自己的资源所有者身份验证，则客户端重定向端点必须要求使用TLS。
Authorization codes MUST be short lived and single-use. If the authorization server observes multiple attempts to exchange an authorization code for an access token, the authorization server SHOULD attempt to revoke all access tokens already granted based on the compromised authorization code.
授权代码必须是短期且一次性使用的。如果授权服务器观察到多次尝试将授权代码交换为访问令牌，则授权服务器应尝试撤销已根据泄露的授权代码授予的所有访问令牌。
If the client can be authenticated, the authorization servers MUST authenticate the client and ensure that the authorization code was issued to the same client.
如果可以对客户端进行身份验证，则授权服务器必须对客户端进行身份验证，并确保向同一客户端颁发了授权代码。
When requesting authorization using the authorization code grant type, the client can specify a redirection URI via the "redirect_uri" parameter. If an attacker can manipulate the value of the redirection URI, it can cause the authorization server to redirect the resource owner user-agent to a URI under the control of the attacker with the authorization code.
当使用授权码授权类型请求授权时，客户端可以通过“redirect_URI”参数指定重定向URI。如果攻击者可以操纵重定向URI的值，则会导致授权服务器使用授权代码将资源所有者用户代理重定向到攻击者控制下的URI。
An attacker can create an account at a legitimate client and initiate the authorization flow. When the attacker's user-agent is sent to the authorization server to grant access, the attacker grabs the authorization URI provided by the legitimate client and replaces the
攻击者可以在合法客户端创建帐户并启动授权流。当攻击者的用户代理被发送到授权服务器以授予访问权限时，攻击者会获取合法客户端提供的授权URI并替换
client's redirection URI with a URI under the control of the attacker. The attacker then tricks the victim into following the manipulated link to authorize access to the legitimate client.
客户端的重定向URI具有受攻击者控制的URI。然后，攻击者诱使受害者跟随被操纵的链接以授权访问合法客户端。
Once at the authorization server, the victim is prompted with a normal, valid request on behalf of a legitimate and trusted client, and authorizes the request. The victim is then redirected to an endpoint under the control of the attacker with the authorization code. The attacker completes the authorization flow by sending the authorization code to the client using the original redirection URI provided by the client. The client exchanges the authorization code with an access token and links it to the attacker's client account, which can now gain access to the protected resources authorized by the victim (via the client).
一旦到达授权服务器，受害者将收到代表合法可信客户端的正常有效请求的提示，并授权该请求。然后，受害者被重定向到一个端点，该端点由攻击者使用授权代码控制。攻击者通过使用客户端提供的原始重定向URI向客户端发送授权代码来完成授权流。客户端使用访问令牌交换授权代码，并将其链接到攻击者的客户端帐户，该帐户现在可以（通过客户端）访问受害者授权的受保护资源。
In order to prevent such an attack, the authorization server MUST ensure that the redirection URI used to obtain the authorization code is identical to the redirection URI provided when exchanging the authorization code for an access token. The authorization server MUST require public clients and SHOULD require confidential clients to register their redirection URIs. If a redirection URI is provided in the request, the authorization server MUST validate it against the registered value.
为了防止此类攻击，授权服务器必须确保用于获取授权代码的重定向URI与将授权代码交换为访问令牌时提供的重定向URI相同。授权服务器必须要求公共客户端，并要求机密客户端注册其重定向URI。如果请求中提供了重定向URI，则授权服务器必须根据注册值对其进行验证。
The resource owner password credentials grant type is often used for legacy or migration reasons. It reduces the overall risk of storing usernames and passwords by the client but does not eliminate the need to expose highly privileged credentials to the client.
资源所有者密码凭据授予类型通常用于遗留或迁移原因。它降低了客户端存储用户名和密码的总体风险，但并不消除向客户端公开高度特权凭据的需要。
This grant type carries a higher risk than other grant types because it maintains the password anti-pattern this protocol seeks to avoid. The client could abuse the password, or the password could unintentionally be disclosed to an attacker (e.g., via log files or other records kept by the client).
此授权类型比其他授权类型具有更高的风险，因为它维护此协议试图避免的密码反模式。客户端可能会滥用密码，或者密码可能会无意中泄露给攻击者（例如，通过客户端保存的日志文件或其他记录）。
Additionally, because the resource owner does not have control over the authorization process (the resource owner's involvement ends when it hands over its credentials to the client), the client can obtain access tokens with a broader scope than desired by the resource owner. The authorization server should consider the scope and lifetime of access tokens issued via this grant type.
此外，由于资源所有者对授权过程没有控制权（资源所有者的参与在将其凭证移交给客户端时结束），因此客户端可以获得范围比资源所有者所期望的更广的访问令牌。授权服务器应该考虑通过这种授予类型发布的访问令牌的范围和生存期。
The authorization server and client SHOULD minimize use of this grant type and utilize other grant types whenever possible.
授权服务器和客户端应尽量减少使用此授权类型，并尽可能使用其他授权类型。
Access tokens, refresh tokens, resource owner passwords, and client credentials MUST NOT be transmitted in the clear. Authorization codes SHOULD NOT be transmitted in the clear.
访问令牌、刷新令牌、资源所有者密码和客户端凭据不得以明文形式传输。授权代码不应以明文形式传输。
The "state" and "scope" parameters SHOULD NOT include sensitive client or resource owner information in plain text, as they can be transmitted over insecure channels or stored insecurely.
“状态”和“范围”参数不应包括明文形式的敏感客户端或资源所有者信息，因为它们可能通过不安全的通道传输或不安全地存储。
In order to prevent man-in-the-middle attacks, the authorization server MUST require the use of TLS with server authentication as defined by [RFC2818] for any request sent to the authorization and token endpoints. The client MUST validate the authorization server's TLS certificate as defined by [RFC6125] and in accordance with its requirements for server identity authentication.
为了防止中间人攻击，授权服务器必须要求对发送到授权和令牌端点的任何请求使用具有[RFC2818]定义的服务器身份验证的TLS。客户机必须按照[RFC6125]的定义并根据其对服务器身份验证的要求验证授权服务器的TLS证书。
The authorization server MUST prevent attackers from guessing access tokens, authorization codes, refresh tokens, resource owner passwords, and client credentials.
授权服务器必须防止攻击者猜测访问令牌、授权代码、刷新令牌、资源所有者密码和客户端凭据。
The probability of an attacker guessing generated tokens (and other credentials not intended for handling by end-users) MUST be less than or equal to 2^(-128) and SHOULD be less than or equal to 2^(-160).
攻击者猜测生成的令牌（以及不打算由最终用户处理的其他凭据）的概率必须小于或等于2^（-128），并且应小于或等于2^（-160）。
The authorization server MUST utilize other means to protect credentials intended for end-user usage.
授权服务器必须使用其他方法来保护最终用户使用的凭据。
Wide deployment of this and similar protocols may cause end-users to become inured to the practice of being redirected to websites where they are asked to enter their passwords. If end-users are not careful to verify the authenticity of these websites before entering their credentials, it will be possible for attackers to exploit this practice to steal resource owners' passwords.
此协议和类似协议的广泛部署可能会导致最终用户习惯于被重定向到要求输入密码的网站。如果最终用户在输入其凭据之前不小心验证这些网站的真实性，攻击者就有可能利用这种做法窃取资源所有者的密码。
Service providers should attempt to educate end-users about the risks phishing attacks pose and should provide mechanisms that make it easy for end-users to confirm the authenticity of their sites. Client developers should consider the security implications of how they interact with the user-agent (e.g., external, embedded), and the ability of the end-user to verify the authenticity of the authorization server.
服务提供商应尝试向最终用户宣传网络钓鱼攻击带来的风险，并应提供机制，使最终用户能够轻松确认其网站的真实性。客户端开发人员应该考虑它们如何与用户代理（例如，外部、嵌入式）交互的安全含义，以及终端用户验证授权服务器的真实性的能力。
To reduce the risk of phishing attacks, the authorization servers MUST require the use of TLS on every endpoint used for end-user interaction.
为了降低网络钓鱼攻击的风险，授权服务器必须要求在用于最终用户交互的每个端点上使用TLS。
Cross-site request forgery (CSRF) is an exploit in which an attacker causes the user-agent of a victim end-user to follow a malicious URI (e.g., provided to the user-agent as a misleading link, image, or redirection) to a trusting server (usually established via the presence of a valid session cookie).
跨站点请求伪造（CSRF）是一种攻击，攻击者利用此漏洞使受害最终用户的用户代理跟随恶意URI（例如，作为误导性链接、映像或重定向提供给用户代理）到信任服务器（通常通过存在有效的会话cookie建立）。
A CSRF attack against the client's redirection URI allows an attacker to inject its own authorization code or access token, which can result in the client using an access token associated with the attacker's protected resources rather than the victim's (e.g., save the victim's bank account information to a protected resource controlled by the attacker).
针对客户端重定向URI的CSRF攻击允许攻击者注入自己的授权代码或访问令牌，这可能导致客户端使用与攻击者受保护资源相关联的访问令牌，而不是受害者的（例如，将受害者的银行帐户信息保存到攻击者控制的受保护资源中）。
The client MUST implement CSRF protection for its redirection URI. This is typically accomplished by requiring any request sent to the redirection URI endpoint to include a value that binds the request to the user-agent's authenticated state (e.g., a hash of the session cookie used to authenticate the user-agent). The client SHOULD utilize the "state" request parameter to deliver this value to the authorization server when making an authorization request.
客户端必须对其重定向URI实施CSRF保护。这通常是通过要求发送到重定向URI端点的任何请求包含将请求绑定到用户代理的已验证状态的值（例如，用于验证用户代理的会话cookie的散列）来实现的。在发出授权请求时，客户端应利用“state”请求参数将该值传递给授权服务器。
Once authorization has been obtained from the end-user, the authorization server redirects the end-user's user-agent back to the client with the required binding value contained in the "state" parameter. The binding value enables the client to verify the validity of the request by matching the binding value to the user-agent's authenticated state. The binding value used for CSRF protection MUST contain a non-guessable value (as described in Section 10.10), and the user-agent's authenticated state (e.g., session cookie, HTML5 local storage) MUST be kept in a location accessible only to the client and the user-agent (i.e., protected by same-origin policy).
从最终用户获得授权后，授权服务器将最终用户的用户代理重定向回客户端，并使用“state”参数中包含的所需绑定值。绑定值使客户端能够通过将绑定值与用户代理的已验证状态相匹配来验证请求的有效性。用于CSRF保护的绑定值必须包含一个不可猜测的值（如第10.10节所述），并且用户代理的身份验证状态（例如，会话cookie、HTML5本地存储）必须保存在只有客户端和用户代理才能访问的位置（即，受同源策略保护）。
A CSRF attack against the authorization server's authorization endpoint can result in an attacker obtaining end-user authorization for a malicious client without involving or alerting the end-user.
针对授权服务器授权端点的CSRF攻击可导致攻击者获得恶意客户端的最终用户授权，而不涉及或提醒最终用户。
The authorization server MUST implement CSRF protection for its authorization endpoint and ensure that a malicious client cannot obtain authorization without the awareness and explicit consent of the resource owner.
授权服务器必须为其授权端点实施CSRF保护，并确保恶意客户端在没有资源所有者的意识和明确同意的情况下无法获得授权。
In a clickjacking attack, an attacker registers a legitimate client and then constructs a malicious site in which it loads the authorization server's authorization endpoint web page in a transparent iframe overlaid on top of a set of dummy buttons, which are carefully constructed to be placed directly under important buttons on the authorization page. When an end-user clicks a misleading visible button, the end-user is actually clicking an invisible button on the authorization page (such as an "Authorize" button). This allows an attacker to trick a resource owner into granting its client access without the end-user's knowledge.
在点击劫持攻击中，攻击者注册一个合法客户端，然后构建一个恶意站点，在该站点中，攻击者将授权服务器的授权端点网页加载到覆盖在一组虚拟按钮之上的透明iframe中，它们经过精心设计，直接放置在授权页面上的重要按钮下方。当最终用户单击一个误导性的可见按钮时，最终用户实际上是在单击授权页面上的一个不可见按钮（例如“授权”按钮）。这使得攻击者能够欺骗资源所有者在最终用户不知情的情况下授予其客户端访问权限。
To prevent this form of attack, native applications SHOULD use external browsers instead of embedding browsers within the application when requesting end-user authorization. For most newer browsers, avoidance of iframes can be enforced by the authorization server using the (non-standard) "x-frame-options" header. This header can have two values, "deny" and "sameorigin", which will block any framing, or framing by sites with a different origin, respectively. For older browsers, JavaScript frame-busting techniques can be used but may not be effective in all browsers.
为了防止这种形式的攻击，当请求最终用户授权时，本机应用程序应该使用外部浏览器，而不是在应用程序中嵌入浏览器。对于大多数较新的浏览器，授权服务器可以使用（非标准）“x-frame-options”头强制避免iFrame。此标头可以有两个值，“deny”和“sameorigin”，这将分别阻止任何帧或具有不同原点的站点的帧。对于较旧的浏览器，可以使用JavaScript框架分解技术，但并非在所有浏览器中都有效。
A code injection attack occurs when an input or otherwise external variable is used by an application unsanitized and causes modification to the application logic. This may allow an attacker to gain access to the application device or its data, cause denial of service, or introduce a wide range of malicious side-effects.
当未初始化的应用程序使用输入或其他外部变量并导致修改应用程序逻辑时，就会发生代码注入攻击。这可能使攻击者能够访问应用程序设备或其数据，导致拒绝服务，或引入广泛的恶意副作用。
The authorization server and client MUST sanitize (and validate when possible) any value received -- in particular, the value of the "state" and "redirect_uri" parameters.
授权服务器和客户端必须清理（并在可能时验证）接收到的任何值，特别是“state”和“redirect_uri”参数的值。
The authorization server, authorization endpoint, and client redirection endpoint can be improperly configured and operate as open redirectors. An open redirector is an endpoint using a parameter to automatically redirect a user-agent to the location specified by the parameter value without any validation.
授权服务器、授权端点和客户端重定向端点可能配置不正确，并作为打开的重定向器运行。打开的重定向程序是一个端点，它使用参数自动将用户代理重定向到参数值指定的位置，而无需任何验证。
Open redirectors can be used in phishing attacks, or by an attacker to get end-users to visit malicious sites by using the URI authority component of a familiar and trusted destination. In addition, if the authorization server allows the client to register only part of the redirection URI, an attacker can use an open redirector operated by
开放式重定向器可用于网络钓鱼攻击，或由攻击者通过使用熟悉且受信任的目的地的URI授权组件让最终用户访问恶意网站。此外，如果授权服务器允许客户端仅注册重定向URI的一部分，则攻击者可以使用由
the client to construct a redirection URI that will pass the authorization server validation but will send the authorization code or access token to an endpoint under the control of the attacker.
客户端需要构造重定向URI，该URI将通过授权服务器验证，但将在攻击者的控制下向端点发送授权代码或访问令牌。
10.16. Misuse of Access Token to Impersonate Resource Owner in Implicit Flow
10.16. 在隐式流中滥用访问令牌来模拟资源所有者
For public clients using implicit flows, this specification does not provide any method for the client to determine what client an access token was issued to.
对于使用隐式流的公共客户端，此规范不为客户端提供任何方法来确定向哪个客户端发出了访问令牌。
A resource owner may willingly delegate access to a resource by granting an access token to an attacker's malicious client. This may be due to phishing or some other pretext. An attacker may also steal a token via some other mechanism. An attacker may then attempt to impersonate the resource owner by providing the access token to a legitimate public client.
资源所有者可以通过向攻击者的恶意客户端授予访问令牌，自愿委托对资源的访问。这可能是由于网络钓鱼或其他借口。攻击者还可以通过其他机制窃取令牌。然后，攻击者可能试图通过向合法的公共客户端提供访问令牌来模拟资源所有者。
In the implicit flow (response_type=token), the attacker can easily switch the token in the response from the authorization server, replacing the real access token with the one previously issued to the attacker.
在隐式流（response_type=token）中，攻击者可以轻松地从授权服务器切换响应中的令牌，用之前发给攻击者的令牌替换真实的访问令牌。
Servers communicating with native applications that rely on being passed an access token in the back channel to identify the user of the client may be similarly compromised by an attacker creating a compromised application that can inject arbitrary stolen access tokens.
与依赖在后台通道中传递访问令牌以识别客户端用户的本机应用程序通信的服务器可能会受到攻击者的类似危害，攻击者创建了一个可注入任意被盗访问令牌的受损应用程序。
Any public client that makes the assumption that only the resource owner can present it with a valid access token for the resource is vulnerable to this type of attack.
任何假定只有资源所有者才能向其提供资源的有效访问令牌的公共客户端都容易受到此类攻击。
This type of attack may expose information about the resource owner at the legitimate client to the attacker (malicious client). This will also allow the attacker to perform operations at the legitimate client with the same permissions as the resource owner who originally granted the access token or authorization code.
这种类型的攻击可能会将合法客户端上的资源所有者信息暴露给攻击者（恶意客户端）。这还将允许攻击者在合法客户端上执行操作，其权限与最初授予访问令牌或授权代码的资源所有者相同。
Authenticating resource owners to clients is out of scope for this specification. Any specification that uses the authorization process as a form of delegated end-user authentication to the client (e.g., third-party sign-in service) MUST NOT use the implicit flow without additional security mechanisms that would enable the client to determine if the access token was issued for its use (e.g., audience-restricting the access token).
向客户端验证资源所有者超出了本规范的范围。任何使用授权流程作为委托给客户端的最终用户身份验证形式的规范（例如，第三方登录服务）都不得使用隐式流，而不使用其他安全机制，这些机制将使客户端能够确定访问令牌是否是为其使用而颁发的（例如，观众限制访问令牌）。
This specification establishes the OAuth Access Token Types registry.
本规范建立OAuth访问令牌类型注册表。
Access token types are registered with a Specification Required ([RFC5226]) after a two-week review period on the oauth-ext-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published.
访问令牌类型在oauth ext上经过两周的审查后，按照所需规范（[RFC5226]）注册-review@ietf.org根据一名或多名指定专家的建议，提供邮件列表。但是，为了允许在发布前分配值，指定专家可在确信此类规范将发布后批准注册。
Registration requests must be sent to the oauth-ext-review@ietf.org mailing list for review and comment, with an appropriate subject (e.g., "Request for access token type: example").
注册请求必须发送到oauth ext-review@ietf.org用于审查和评论的邮件列表，带有适当的主题（例如，“访问令牌类型请求：示例”）。
Within the review period, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful.
在审查期内，指定专家将批准或拒绝注册请求，并将该决定告知审查名单和IANA。拒绝应包括解释，以及（如适用）关于如何使请求成功的建议。
IANA must only accept registry updates from the Designated Expert(s) and should direct all requests for registration to the review mailing list.
IANA必须只接受指定专家的注册更新，并将所有注册请求发送至审查邮件列表。
Type name: The name requested (e.g., "example").
类型名称：请求的名称（例如，“示例”）。
Additional Token Endpoint Response Parameters: Additional response parameters returned together with the "access_token" parameter. New parameters MUST be separately registered in the OAuth Parameters registry as described by Section 11.2.
附加令牌端点响应参数：与“access\u Token”参数一起返回的附加响应参数。新参数必须在OAuth参数注册表中单独注册，如第11.2节所述。
HTTP Authentication Scheme(s): The HTTP authentication scheme name(s), if any, used to authenticate protected resource requests using access tokens of this type.
HTTP身份验证方案：HTTP身份验证方案名称（如果有），用于使用此类型的访问令牌对受保护的资源请求进行身份验证。
Change controller: For Standards Track RFCs, state "IETF". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.
更改控制器：对于标准跟踪RFC，请注明“IETF”。对于其他人，请提供责任方的名称。还可以包括其他详细信息（例如，邮政地址、电子邮件地址、主页URI）。
Specification document(s): Reference to the document(s) that specify the parameter, preferably including a URI that can be used to retrieve a copy of the document(s). An indication of the relevant sections may also be included but is not required.
规范文档：对指定参数的文档的引用，最好包括可用于检索文档副本的URI。也可以包括相关章节的指示，但不需要。
This specification establishes the OAuth Parameters registry.
本规范建立OAuth参数注册表。
Additional parameters for inclusion in the authorization endpoint request, the authorization endpoint response, the token endpoint request, or the token endpoint response are registered with a Specification Required ([RFC5226]) after a two-week review period on the oauth-ext-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published.
授权端点请求、授权端点响应、令牌端点请求或令牌端点响应中包含的其他参数在oauth ext上经过两周的审查期后，按照所需规范（[RFC5226]）注册-review@ietf.org邮寄名单，根据一名或多名指定专家的建议。但是，为了允许在发布前分配值，指定专家可在确信此类规范将发布后批准注册。
Registration requests must be sent to the oauth-ext-review@ietf.org mailing list for review and comment, with an appropriate subject (e.g., "Request for parameter: example").
注册请求必须发送到oauth ext-review@ietf.org用于审查和评论的邮件列表，带有适当的主题（例如，“参数请求：示例”）。
Within the review period, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful.
在审查期内，指定专家将批准或拒绝注册请求，并将该决定告知审查名单和IANA。拒绝应包括解释，以及（如适用）关于如何使请求成功的建议。
IANA must only accept registry updates from the Designated Expert(s) and should direct all requests for registration to the review mailing list.
IANA必须只接受指定专家的注册更新，并将所有注册请求发送至审查邮件列表。
Parameter name: The name requested (e.g., "example").
参数名称：请求的名称（例如，“示例”）。
Parameter usage location: The location(s) where parameter can be used. The possible locations are authorization request, authorization response, token request, or token response.
参数使用位置：可以使用参数的位置。可能的位置是授权请求、授权响应、令牌请求或令牌响应。
Change controller: For Standards Track RFCs, state "IETF". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.
更改控制器：对于标准跟踪RFC，请注明“IETF”。对于其他人，请提供责任方的名称。还可以包括其他详细信息（例如，邮政地址、电子邮件地址、主页URI）。
Specification document(s): Reference to the document(s) that specify the parameter, preferably including a URI that can be used to retrieve a copy of the document(s). An indication of the relevant sections may also be included but is not required.
规范文档：对指定参数的文档的引用，最好包括可用于检索文档副本的URI。也可以包括相关章节的指示，但不需要。
The OAuth Parameters registry's initial contents are:
OAuth参数注册表的初始内容是：
o Parameter name: client_id o Parameter usage location: authorization request, token request o Change controller: IETF o Specification document(s): RFC 6749
o 参数名称：客户端id o参数使用位置：授权请求、令牌请求o更改控制器：IETF o规范文档：RFC 6749
o Parameter name: client_secret o Parameter usage location: token request o Change controller: IETF o Specification document(s): RFC 6749
o 参数名称：客户端密码o参数使用位置：令牌请求o更改控制器：IETF o规范文档：RFC 6749
o Parameter name: response_type o Parameter usage location: authorization request o Change controller: IETF o Specification document(s): RFC 6749
o 参数名称：响应类型o参数使用位置：授权请求o变更控制器：IETF o规范文件：RFC 6749
o Parameter name: redirect_uri o Parameter usage location: authorization request, token request o Change controller: IETF o Specification document(s): RFC 6749
o 参数名称：重定向\u uri o参数使用位置：授权请求、令牌请求o更改控制器：IETF o规范文档：RFC 6749
o Parameter name: scope o Parameter usage location: authorization request, authorization response, token request, token response o Change controller: IETF o Specification document(s): RFC 6749
o 参数名称：范围o参数使用位置：授权请求、授权响应、令牌请求、令牌响应o更改控制器：IETF o规范文档：RFC 6749
o Parameter name: state o Parameter usage location: authorization request, authorization response o Change controller: IETF o Specification document(s): RFC 6749
o 参数名称：状态o参数使用位置：授权请求、授权响应o更改控制器：IETF o规范文件：RFC 6749
o Parameter name: code o Parameter usage location: authorization response, token request o Change controller: IETF o Specification document(s): RFC 6749
o 参数名称：代码o参数使用位置：授权响应、令牌请求o更改控制器：IETF o规范文档：RFC 6749
o Parameter name: error_description o Parameter usage location: authorization response, token response o Change controller: IETF o Specification document(s): RFC 6749
o 参数名称：错误描述o参数使用位置：授权响应、令牌响应o更改控制器：IETF o规范文档：RFC 6749
o Parameter name: error_uri o Parameter usage location: authorization response, token response o Change controller: IETF o Specification document(s): RFC 6749
o 参数名称：error_uri o参数使用位置：授权响应、令牌响应o更改控制器：IETF o规范文档：RFC 6749
o Parameter name: grant_type o Parameter usage location: token request o Change controller: IETF o Specification document(s): RFC 6749
o 参数名称：授权类型o参数使用位置：令牌请求o更改控制器：IETF o规范文档：RFC 6749
o Parameter name: access_token o Parameter usage location: authorization response, token response o Change controller: IETF o Specification document(s): RFC 6749
o 参数名称：访问令牌o参数使用位置：授权响应、令牌响应o更改控制器：IETF o规范文档：RFC 6749
o Parameter name: token_type o Parameter usage location: authorization response, token response o Change controller: IETF o Specification document(s): RFC 6749
o 参数名称：令牌类型o参数使用位置：授权响应、令牌响应o更改控制器：IETF o规范文档：RFC 6749
o Parameter name: expires_in o Parameter usage location: authorization response, token response o Change controller: IETF o Specification document(s): RFC 6749
o 参数名称：expires_in o参数使用位置：授权响应、令牌响应o更改控制器：IETF o规范文档：RFC 6749
o Parameter name: username o Parameter usage location: token request o Change controller: IETF o Specification document(s): RFC 6749
o 参数名称：用户名o参数使用位置：令牌请求o更改控制器：IETF o规范文档：RFC 6749
o Parameter name: password o Parameter usage location: token request o Change controller: IETF o Specification document(s): RFC 6749
o 参数名称：密码o参数使用位置：令牌请求o更改控制器：IETF o规范文档：RFC 6749
o Parameter name: refresh_token o Parameter usage location: token request, token response o Change controller: IETF o Specification document(s): RFC 6749
o 参数名称：刷新令牌o参数使用位置：令牌请求、令牌响应o更改控制器：IETF o规范文档：RFC 6749
This specification establishes the OAuth Authorization Endpoint Response Types registry.
本规范建立OAuth授权端点响应类型注册表。
Additional response types for use with the authorization endpoint are registered with a Specification Required ([RFC5226]) after a two-week review period on the oauth-ext-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published.
在oauth ext上经过两周的审查后，使用所需的规范（[RFC5226]）注册用于授权端点的其他响应类型-review@ietf.org根据一名或多名指定专家的建议，提供邮件列表。但是，为了允许在发布前分配值，指定专家可在确信此类规范将发布后批准注册。
Registration requests must be sent to the oauth-ext-review@ietf.org mailing list for review and comment, with an appropriate subject (e.g., "Request for response type: example").
注册请求必须发送到oauth ext-review@ietf.org用于审查和评论的邮件列表，带有适当的主题（例如，“请求回复类型：示例”）。
Within the review period, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful.
在审查期内，指定专家将批准或拒绝注册请求，并将该决定告知审查名单和IANA。拒绝应包括解释，以及（如适用）关于如何使请求成功的建议。
IANA must only accept registry updates from the Designated Expert(s) and should direct all requests for registration to the review mailing list.
IANA必须只接受指定专家的注册更新，并将所有注册请求发送至审查邮件列表。
Response type name: The name requested (e.g., "example").
响应类型名称：请求的名称（例如，“示例”）。
Change controller: For Standards Track RFCs, state "IETF". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.
更改控制器：对于标准跟踪RFC，请注明“IETF”。对于其他人，请提供责任方的名称。还可以包括其他详细信息（例如，邮政地址、电子邮件地址、主页URI）。
Specification document(s): Reference to the document(s) that specify the type, preferably including a URI that can be used to retrieve a copy of the document(s). An indication of the relevant sections may also be included but is not required.
规范文档：对指定类型的文档的引用，最好包括可用于检索文档副本的URI。也可以包括相关章节的指示，但不需要。
The OAuth Authorization Endpoint Response Types registry's initial contents are:
OAuth授权端点响应类型注册表的初始内容为：
o Response type name: code o Change controller: IETF o Specification document(s): RFC 6749
o 响应类型名称：代码o变更控制器：IETF o规范文件：RFC 6749
o Response type name: token o Change controller: IETF o Specification document(s): RFC 6749
o 响应类型名称：令牌o更改控制器：IETF o规范文件：RFC 6749
This specification establishes the OAuth Extensions Error registry.
本规范建立OAuth扩展错误注册表。
Additional error codes used together with other protocol extensions (i.e., extension grant types, access token types, or extension parameters) are registered with a Specification Required ([RFC5226]) after a two-week review period on the oauth-ext-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published.
在oauth ext上经过两周的审查后，与其他协议扩展（即扩展授权类型、访问令牌类型或扩展参数）一起使用的其他错误代码将按照所需规范（[RFC5226]）进行注册-review@ietf.org根据一名或多名指定专家的建议，提供邮件列表。但是，为了允许在发布前分配值，指定专家可在确信此类规范将发布后批准注册。
Registration requests must be sent to the oauth-ext-review@ietf.org mailing list for review and comment, with an appropriate subject (e.g., "Request for error code: example").
注册请求必须发送到oauth ext-review@ietf.org用于审查和评论的邮件列表，带有适当的主题（例如，“错误代码请求：示例”）。
Within the review period, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful.
在审查期内，指定专家将批准或拒绝注册请求，并将该决定告知审查名单和IANA。拒绝应包括解释，以及（如适用）关于如何使请求成功的建议。
IANA must only accept registry updates from the Designated Expert(s) and should direct all requests for registration to the review mailing list.
IANA必须只接受指定专家的注册更新，并将所有注册请求发送至审查邮件列表。
Error name: The name requested (e.g., "example"). Values for the error name MUST NOT include characters outside the set %x20-21 / %x23-5B / %x5D-7E.
错误名称：请求的名称（例如，“示例”）。错误名称的值不得包含集合%x20-21/%x23-5B/%x5D-7E之外的字符。
Error usage location: The location(s) where the error can be used. The possible locations are authorization code grant error response (Section 4.1.2.1), implicit grant error response (Section 4.2.2.1), token error response (Section 5.2), or resource access error response (Section 7.2).
错误使用位置：可以使用错误的位置。可能的位置是授权码授予错误响应（第4.1.2.1节）、隐式授予错误响应（第4.2.2.1节）、令牌错误响应（第5.2节）或资源访问错误响应（第7.2节）。
Related protocol extension: The name of the extension grant type, access token type, or extension parameter that the error code is used in conjunction with.
相关协议扩展：与错误代码一起使用的扩展授权类型、访问令牌类型或扩展参数的名称。
Change controller: For Standards Track RFCs, state "IETF". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.
更改控制器：对于标准跟踪RFC，请注明“IETF”。对于其他人，请提供责任方的名称。还可以包括其他详细信息（例如，邮政地址、电子邮件地址、主页URI）。
Specification document(s): Reference to the document(s) that specify the error code, preferably including a URI that can be used to retrieve a copy of the document(s). An indication of the relevant sections may also be included but is not required.
规范文档：对指定错误代码的文档的引用，最好包括可用于检索文档副本的URI。也可以包括相关章节的指示，但不需要。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC2246，1999年1月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2617]Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.，和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC4627]Crockford，D.，“JavaScript对象表示法（json）的应用程序/json媒体类型”，RFC4627，2006年7月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC4949]Shirey，R.，“互联网安全术语表，第2版”，RFC 49492007年8月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施中表示和验证基于域的应用程序服务标识”，RFC 61252011年3月。
[USASCII] American National Standards Institute, "Coded Character Set -- 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986.
[USASCII]美国国家标准协会，“编码字符集——信息交换用7位美国标准代码”，ANSI X3.41986。
[W3C.REC-html401-19991224] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01 Specification", World Wide Web Consortium Recommendation REC-html401-19991224, December 1999, <http://www.w3.org/TR/1999/REC-html401-19991224>.
[W3C.REC-html401-19991224]Raggett，D.，Le Hors，A.和I.Jacobs，“HTML 4.01规范”，万维网联盟建议REC-html401-19991224，1999年12月<http://www.w3.org/TR/1999/REC-html401-19991224>.
[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <http://www.w3.org/TR/2008/REC-xml-20081126>.
[W3C.REC-xml-20081126]Bray，T.，Paoli，J.，Sperberg McQueen，C.，Maler，E.，和F.Yergeau，“可扩展标记语言（xml）1.0（第五版）”，万维网联盟建议REC-xml-20081126，2008年11月<http://www.w3.org/TR/2008/REC-xml-20081126>.
[OAuth-HTTP-MAC] Hammer-Lahav, E., Ed., "HTTP Authentication: MAC Access Authentication", Work in Progress, February 2012.
[OAuth HTTP MAC]Hammer Lahav，E.，编辑，“HTTP认证：MAC访问认证”，正在进行的工作，2012年2月。
[OAuth-SAML2] Campbell, B. and C. Mortimore, "SAML 2.0 Bearer Assertion Profiles for OAuth 2.0", Work in Progress, September 2012.
[OAuth-SAML2]Campbell，B.和C.Mortimore，“OAuth 2.0的SAML 2.0承载断言配置文件”，正在进行的工作，2012年9月。
[OAuth-THREATMODEL] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 Threat Model and Security Considerations", Work in Progress, October 2012.
[OAuth威胁模型]Lodderstedt，T.，Ed.，McGloin，M.，和P.Hunt，“OAuth 2.0威胁模型和安全注意事项”，正在进行的工作，2012年10月。
[OAuth-WRAP] Hardt, D., Ed., Tom, A., Eaton, B., and Y. Goland, "OAuth Web Resource Authorization Profiles", Work in Progress, January 2010.
[OAuth WRAP]Hardt，D.，Ed.，Tom，A.，Eaton，B.，和Y.Goland，“OAuth Web资源授权配置文件”，正在进行的工作，2010年1月。
[RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, April 2010.
[RFC5849]Hammer Lahav，E.“OAuth 1.0协议”，RFC 5849，2010年4月。
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, October 2012.
[RFC6750]Jones，M.和D.Hardt，“OAuth 2.0授权框架：承载令牌使用”，RFC 67502012年10月。
Appendix A. Augmented Backus-Naur Form (ABNF) Syntax
附录A.扩充的巴科斯诺尔形式（ABNF）语法
This section provides Augmented Backus-Naur Form (ABNF) syntax descriptions for the elements defined in this specification using the notation of [RFC5234]. The ABNF below is defined in terms of Unicode code points [W3C.REC-xml-20081126]; these characters are typically encoded in UTF-8. Elements are presented in the order first defined.
本节使用[RFC5234]符号为本规范中定义的元素提供了扩展的巴科斯诺尔形式（ABNF）语法描述。下面的ABNF是根据Unicode代码点定义的[W3C.REC-xml-20081126]；这些字符通常以UTF-8编码。元素按首先定义的顺序显示。
Some of the definitions that follow use the "URI-reference" definition from [RFC3986].
下面的一些定义使用了[RFC3986]中的“URI引用”定义。
Some of the definitions that follow use these common definitions:
下面的一些定义使用以下常用定义：
VSCHAR = %x20-7E
NQCHAR = %x21 / %x23-5B / %x5D-7E
NQSCHAR = %x20-21 / %x23-5B / %x5D-7E
UNICODECHARNOCRLF = %x09 /%x20-7E / %x80-D7FF /
%xE000-FFFD / %x10000-10FFFF
VSCHAR = %x20-7E
NQCHAR = %x21 / %x23-5B / %x5D-7E
NQSCHAR = %x20-21 / %x23-5B / %x5D-7E
UNICODECHARNOCRLF = %x09 /%x20-7E / %x80-D7FF /
%xE000-FFFD / %x10000-10FFFF
(The UNICODECHARNOCRLF definition is based upon the Char definition in Section 2.2 of [W3C.REC-xml-20081126], but omitting the Carriage Return and Linefeed characters.)
（UNICODECHARNOCRLF定义基于[W3C.REC-xml-20081126]第2.2节中的字符定义，但省略了回车符和换行符。）
The "client_id" element is defined in Section 2.3.1:
第2.3.1节定义了“客户id”元素：
client-id = *VSCHAR
client-id = *VSCHAR
The "client_secret" element is defined in Section 2.3.1:
第2.3.1节定义了“客户机密”元素：
client-secret = *VSCHAR
client-secret = *VSCHAR
The "response_type" element is defined in Sections 3.1.1 and 8.4:
第3.1.1节和第8.4节定义了“响应类型”元素：
response-type = response-name *( SP response-name )
response-name = 1*response-char
response-char = "_" / DIGIT / ALPHA
response-type = response-name *( SP response-name )
response-name = 1*response-char
response-char = "_" / DIGIT / ALPHA
The "scope" element is defined in Section 3.3:
第3.3节定义了“范围”要素：
scope = scope-token *( SP scope-token )
scope-token = 1*NQCHAR
scope = scope-token *( SP scope-token )
scope-token = 1*NQCHAR
The "state" element is defined in Sections 4.1.1, 4.1.2, 4.1.2.1, 4.2.1, 4.2.2, and 4.2.2.1:
第4.1.1、4.1.2、4.1.2.1、4.2.1、4.2.2和4.2.2.1节中定义了“状态”元素：
state = 1*VSCHAR
state = 1*VSCHAR
The "redirect_uri" element is defined in Sections 4.1.1, 4.1.3, and 4.2.1:
第4.1.1节、第4.1.3节和第4.2.1节定义了“重定向uri”元素：
redirect-uri = URI-reference
redirect-uri = URI-reference
The "error" element is defined in Sections 4.1.2.1, 4.2.2.1, 5.2, 7.2, and 8.5:
第4.1.2.1、4.2.2.1、5.2、7.2和8.5节定义了“错误”元素：
error = 1*NQSCHAR
error = 1*NQSCHAR
The "error_description" element is defined in Sections 4.1.2.1, 4.2.2.1, 5.2, and 7.2:
第4.1.2.1节、第4.2.2.1节、第5.2节和第7.2节定义了“错误描述”元素：
error-description = 1*NQSCHAR
error-description = 1*NQSCHAR
The "error_uri" element is defined in Sections 4.1.2.1, 4.2.2.1, 5.2, and 7.2:
第4.1.2.1、4.2.2.1、5.2和7.2节定义了“error_uri”元素：
error-uri = URI-reference
error-uri = URI-reference
The "grant_type" element is defined in Sections 4.1.3, 4.3.2, 4.4.2, 4.5, and 6:
第4.1.3节、第4.3.2节、第4.4.2节、第4.5节和第6节定义了“授予类型”要素：
grant-type = grant-name / URI-reference
grant-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
grant-type = grant-name / URI-reference
grant-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
The "code" element is defined in Section 4.1.3:
第4.1.3节定义了“代码”元素：
code = 1*VSCHAR
code = 1*VSCHAR
The "access_token" element is defined in Sections 4.2.2 and 5.1:
第4.2.2节和第5.1节定义了“访问令牌”元素：
access-token = 1*VSCHAR
access-token = 1*VSCHAR
The "token_type" element is defined in Sections 4.2.2, 5.1, and 8.1:
第4.2.2、5.1和8.1节定义了“令牌类型”元素：
token-type = type-name / URI-reference
type-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
token-type = type-name / URI-reference
type-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
The "expires_in" element is defined in Sections 4.2.2 and 5.1:
第4.2.2节和第5.1节定义了“到期日”元素：
expires-in = 1*DIGIT
expires-in = 1*DIGIT
The "username" element is defined in Section 4.3.2:
第4.3.2节定义了“用户名”元素：
username = *UNICODECHARNOCRLF
username = *UNICODECHARNOCRLF
The "password" element is defined in Section 4.3.2:
第4.3.2节定义了“密码”元素：
password = *UNICODECHARNOCRLF
password = *UNICODECHARNOCRLF
The "refresh_token" element is defined in Sections 5.1 and 6:
第5.1节和第6节定义了“刷新令牌”元素：
refresh-token = 1*VSCHAR
refresh-token = 1*VSCHAR
The syntax for new endpoint parameters is defined in Section 8.2:
第8.2节中定义了新端点参数的语法：
param-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
param-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
Appendix B. Use of application/x-www-form-urlencoded Media Type
附录B.应用程序的使用/x-www-form-URL编码媒体类型
At the time of publication of this specification, the "application/x-www-form-urlencoded" media type was defined in Section 17.13.4 of [W3C.REC-html401-19991224] but not registered in the IANA MIME Media Types registry (<http://www.iana.org/assignments/media-types>). Furthermore, that definition is incomplete, as it does not consider non-US-ASCII characters.
在本规范发布时，“application/x-www-form-urlencoded”媒体类型已在[W3C.REC-html401-19991224]第17.13.4节中定义，但未在IANA MIME媒体类型注册表中注册(<http://www.iana.org/assignments/media-types>). 此外，该定义是不完整的，因为它不考虑非美国ASCII字符。
To address this shortcoming when generating payloads using this media type, names and values MUST be encoded using the UTF-8 character encoding scheme [RFC3629] first; the resulting octet sequence then needs to be further encoded using the escaping rules defined in [W3C.REC-html401-19991224].
为了解决使用此媒体类型生成有效负载时的此缺点，必须首先使用UTF-8字符编码方案[RFC3629]对名称和值进行编码；然后，需要使用[W3C.REC-html401-19991224]中定义的转义规则对生成的八位字节序列进行进一步编码。
When parsing data from a payload using this media type, the names and values resulting from reversing the name/value encoding consequently need to be treated as octet sequences, to be decoded using the UTF-8 character encoding scheme.
当使用此媒体类型解析来自有效负载的数据时，由于反转名称/值编码而产生的名称和值因此需要被视为八位字节序列，以便使用UTF-8字符编码方案进行解码。
For example, the value consisting of the six Unicode code points (1) U+0020 (SPACE), (2) U+0025 (PERCENT SIGN), (3) U+0026 (AMPERSAND), (4) U+002B (PLUS SIGN), (5) U+00A3 (POUND SIGN), and (6) U+20AC (EURO SIGN) would be encoded into the octet sequence below (using hexadecimal notation):
例如，由六个Unicode代码点（1）U+0020（空格），（2）U+0025（百分号），（3）U+0026（和号），（4）U+002B（加号），（5）U+00A3（磅号）和（6）U+20AC（欧号）组成的值将被编码到下面的八位字节序列中（使用十六进制表示法）：
20 25 26 2B C2 A3 E2 82 AC
20 25 26 2B C2 A3 E2 82 AC
and then represented in the payload as:
然后在有效载荷中表示为：
+%25%26%2B%C2%A3%E2%82%AC
+%25%26%2B%C2%A3%E2%82%AC
The initial OAuth 2.0 protocol specification was edited by David Recordon, based on two previous publications: the OAuth 1.0 community specification [RFC5849], and OAuth WRAP (OAuth Web Resource Authorization Profiles) [OAuth-WRAP]. Eran Hammer then edited many of the intermediate drafts that evolved into this RFC. The Security Considerations section was drafted by Torsten Lodderstedt, Mark McGloin, Phil Hunt, Anthony Nadalin, and John Bradley. The section on use of the "application/x-www-form-urlencoded" media type was drafted by Julian Reschke. The ABNF section was drafted by Michael B. Jones.
最初的OAuth 2.0协议规范由David Recordon根据之前的两个出版物进行编辑：OAuth 1.0社区规范[RFC5849]和OAuth WRAP（OAuth Web资源授权配置文件）[OAuth WRAP]。然后，Eran Hammer编辑了许多演变成RFC的中间草稿。安全考虑部分由Torsten Lodderstedt、Mark McGloin、Phil Hunt、Anthony Nadalin和John Bradley起草。关于使用“application/x-www-form-urlencoded”媒体类型的一节由Julian Reschke起草。ABNF部分由Michael B.Jones起草。
The OAuth 1.0 community specification was edited by Eran Hammer and authored by Mark Atwood, Dirk Balfanz, Darren Bounds, Richard M. Conlan, Blaine Cook, Leah Culver, Breno de Medeiros, Brian Eaton, Kellan Elliott-McCrea, Larry Halff, Eran Hammer, Ben Laurie, Chris Messina, John Panzer, Sam Quigley, David Recordon, Eran Sandler, Jonathan Sergent, Todd Sieling, Brian Slesinsky, and Andy Smith.
OAuth 1.0社区规范由Eran Hammer编辑，由Mark Atwood、Dirk Balfanz、Darren Bounds、Richard M.Conlan、Blaine Cook、Leah Culver、Breno de Medeiros、Brian Eaton、Kellan Elliott McCrea、Larry Halff、Eran Hammer、Ben Laurie、Chris Messina、John Panzer、Sam Quigley、David Recordon、Eran Sandler、Jonathan Sergent编写，托德·西林、布赖恩·斯莱辛斯基和安迪·史密斯。
The OAuth WRAP specification was edited by Dick Hardt and authored by Brian Eaton, Yaron Y. Goland, Dick Hardt, and Allen Tom.
OAuth包装规范由Dick Hardt编辑，由Brian Eaton、Yaron Y.Goland、Dick Hardt和Allen Tom编写。
This specification is the work of the OAuth Working Group, which includes dozens of active and dedicated participants. In particular, the following individuals contributed ideas, feedback, and wording that shaped and formed the final specification:
本规范是OAuth工作组的工作，该工作组包括数十名积极和专注的参与者。特别是，以下个人提供了形成最终规范的想法、反馈和措辞：
Michael Adams, Amanda Anganes, Andrew Arnott, Dirk Balfanz, Aiden Bell, John Bradley, Marcos Caceres, Brian Campbell, Scott Cantor, Blaine Cook, Roger Crew, Leah Culver, Bill de hOra, Andre DeMarre, Brian Eaton, Wesley Eddy, Wolter Eldering, Brian Ellin, Igor Faynberg, George Fletcher, Tim Freeman, Luca Frosini, Evan Gilbert, Yaron Y. Goland, Brent Goldman, Kristoffer Gronowski, Eran Hammer, Dick Hardt, Justin Hart, Craig Heath, Phil Hunt, Michael B. Jones, Terry Jones, John Kemp, Mark Kent, Raffi Krikorian, Chasen Le Hara, Rasmus Lerdorf, Torsten Lodderstedt, Hui-Lan Lu, Casey Lucas, Paul Madsen, Alastair Mair, Eve Maler, James Manger, Mark McGloin, Laurence Miao, William Mills, Chuck Mortimore, Anthony Nadalin, Julian Reschke, Justin Richer, Peter Saint-Andre, Nat Sakimura, Rob Sayre, Marius Scurtescu, Naitik Shah, Luke Shepard, Vlad Skvortsov, Justin Smith, Haibin Song, Niv Steingarten, Christian Stuebner, Jeremy Suriel, Paul Tarjan, Christopher Thomas, Henry S. Thompson, Allen Tom, Franklin Tse, Nick Walker, Shane Weeden, and Skylar Woodward.
迈克尔·亚当斯、阿曼达·安加内斯、安德鲁·阿诺特、德克·巴尔芬兹、艾登·贝尔、约翰·布拉德利、马科斯·卡塞雷斯、布莱恩·坎贝尔、斯科特·康托、布莱恩·库克、罗杰·克鲁、利亚·卡尔弗、比尔·德霍拉、安德烈·德马尔、布莱恩·伊顿、卫斯利·艾迪、沃尔特·埃尔德林、布莱恩·埃林、伊戈尔·费恩伯格、乔治·弗莱彻、蒂姆·弗里曼、卢卡·弗罗西尼、埃文·吉尔伯特、雅伦·戈兰、，布伦特·戈德曼、克里斯托弗·格罗诺夫斯基、埃兰·哈默、迪克·哈特、贾斯汀·哈特、克雷格·希思、菲尔·亨特、迈克尔·琼斯、特里·琼斯、约翰·坎普、马克·肯特、拉菲·克里科里安、查森·勒哈拉、拉斯姆斯·勒多夫、托斯滕·洛德斯特德、许兰路、凯西·卢卡斯、保罗·马德森、阿拉斯泰尔·梅尔、伊夫·马勒、詹姆斯·马格尔、马克·麦格伦、劳伦斯·缪、威廉·米尔斯、，查克·莫蒂莫、安东尼·纳达林、朱利安·雷什克、贾斯汀·里希、彼得·圣安德烈、纳特·樱村、罗布·赛尔、马吕斯·斯库特斯库、奈提克·沙阿、卢克·谢泼德、弗拉德·斯克沃佐夫、贾斯汀·史密斯、海滨松、尼夫·斯坦加滕、克里斯蒂安·斯图布纳、杰里米·苏里尔、保罗·塔扬、克里斯托弗·托马斯、亨利·S·汤普森、艾伦·汤姆、富兰克林·谢、尼克·沃克、，Shane Weeden和Skylar Woodward。
This document was produced under the chairmanship of Blaine Cook, Peter Saint-Andre, Hannes Tschofenig, Barry Leiba, and Derek Atkins. The area directors included Lisa Dusseault, Peter Saint-Andre, and Stephen Farrell.
本文件由Blaine Cook、Peter Saint Andre、Hannes Tschofenig、Barry Leiba和Derek Atkins担任主席。区域主管包括Lisa Dusseault、Peter Saint Andre和Stephen Farrell。
Author's Address
作者地址
Dick Hardt (editor) Microsoft
迪克·哈特（编辑）微软
EMail: dick.hardt@gmail.com
URI: http://dickhardt.org/
EMail: dick.hardt@gmail.com
URI: http://dickhardt.org/