RFC6749-The OAuth 2.0 Authorization Framework

摘要（Abstract）

OAuth 2.0授权框架允许第三方应用程序获得对HTTP服务的有限访问，可以代表资源所有者组织资源所有者和HTTP服务之间的审批交互，也可以允许第三方应用程序代表自己获得访问。这个规范取代了RFC 5849中描述的OAuth 1.0协议。

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.

1. 简介（Introduction）

在传统的客户端-服务器身份验证模型中，客户端通过使用资源所有者的凭据与服务器进行身份验证来在服务器上请求访问受限资源（受保护的资源）。 为了使第三方应用程序可以访问受限资源，资源所有者与第三方共享其凭据。 这会带来一些问题和局限性：

• 第三方应用程序需要存储资源所有者的凭证以供将来使用，通常是明文密码。
• 尽管密码存在固有的安全缺陷，但服务器需要支持密码身份验证。
• 第三方应用程序获得了对资源所有者受保护资源的过度广泛的访问，使得资源所有者无法限制持续时间或对有限资源子集的访问。
• 资源所有者不能在不撤销对所有第三方的访问权的情况下撤销对单个第三方的访问权，而且必须通过更改第三方的密码来实现。
• 任何第三方应用程序的泄露都会导致最终用户的密码和该密码保护的所有数据的泄露。

OAuth通过引入授权层并将客户端的角色与资源所有者的角色分开来解决这些问题。在OAuth中，客户端请求访问由资源所有者控制并由资源服务器托管的资源，并向客户端颁发与资源所有者不同的一组凭据。

客户端无需使用资源所有者的凭证来访问受保护的资源，而是获取访问令牌-表示特定范围，生存期和其他访问属性的字符串。访问令牌是由授权服务器在资源所有者的批准下颁发给第三方客户端的。客户端使用访问令牌访问资源服务器托管的受保护资源。

例如，最终用户（资源所有者）可以授予打印服务（客户端）访问存储在照片共享服务（资源服务器）中的受保护照片的权限，而无需与打印服务共享她的用户名和密码。相反，她直接通过照片共享服务信任的服务器（授权服务器）进行身份验证，该服务器颁发特定于打印服务委托的凭据（访问令牌）。

该规范旨在与HTTP（[RFC2616]）一起使用。在除HTTP以外的任何协议上使用OAuth超出了范围。

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的实现者在接近这个文档时应该不需要对它的结构和细节做任何假设。

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 Servers are required to support password authentication, despite the security weaknesses inherent in passwords.

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 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 Compromise of any third-party application results in compromise of the end-user’s password and all of
the data protected by that password.

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.

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.

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.

1.1 角色（roles）

OAuth定义了四种角色:

资源所有者
能够授予对受保护资源的访问权的实体。当资源所有者是人时，它被称为最终用户。
资源服务器
托管受保护资源的服务器，能够使用访问令牌接受和响应受保护的资源请求。
客户端
代表资源所有者并经其授权发出受保护资源请求的应用程序。术语“客户端”并不意味着任何特殊的实现特征(例如，应用程序是否在服务器、桌面或其他设备上执行)。
授权服务器
在成功验证资源所有者并获得授权后，服务器向客户机发出访问令牌。

授权服务器和资源服务器之间的交互超出了本规范的范围。 授权服务器可以是与资源服务器相同的服务器，也可以是单独的实体。单个授权服务器可以颁发多个资源服务器接受的访问令牌。

OAuth defines four roles: 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.

1.2 协议流程（Protocol Flow）

图1所示的抽象OAuth 2.0流程描述了四个角色之间的交互，并包括以下步骤：

(A)客户端请求资源所有者的授权。授权请求可以直接发送给资源所有者(如图所示)，也可以通过授权服务器作为中介间接发送。

(B)客户收到授权授予，这是代表资源所有者授权的凭证，使用本规范中定义的四种授权类型之一或使用扩展授权类型表示。授权授予类型取决于客户端用于请求授权的方法和授权服务器支持的类型。

(C)客户端通过与授权服务器进行身份验证并提供授权授权来请求访问令牌。

(D)授权服务器对客户端进行身份验证并验证授权授予，如果有效，则发出访问令牌。

(E)客户端向资源服务器请求受保护的资源，并出示访问令牌进行身份验证。

(F)资源服务器验证访问令牌，如果有效，则为请求服务。

客户端从资源所有者那里获得授权许可的首选方法（在步骤（A）和（B）中进行了描述）是使用授权服务器作为中介，这在第4.1节的图3中进行了说明。

The abstract OAuth 2.0 flow illustrated in Figure 1 describes the interaction between the four roles and includes the following steps:

(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. (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. (C) The client requests an access token by authenticating with the authorization server and presenting the authorization grant. (D) The authorization server authenticates the client and validates the authorization grant, and if valid, issues an access token. (E) The client requests the protected resource from the resource server and authenticates by presenting the access token. (F) The resource server validates the access token, and if valid, serves the request.

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.

1.3. 授权许可（Authorization Grant）

授权授予是代表客户端使用资源（访问其受保护资源）以获取访问令牌的授权的凭证。该规范定义了四种授予类型——授权码模式、隐式模式、密码凭据模式和客户端模式——以及用于定义其他类型的扩展机制。

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.

1.3.1 授权码（Authorization Code）

通过使用授权服务器作为客户端和资源所有者之间的中介，可以获取授权代码。 客户端不是直接从资源所有者请求授权，而是将资源所有者定向到授权服务器（通过[RFC2616]中定义的用户代理），该服务器进而将资源所有者与授权代码一起引导回客户端。

在使用授权码将资源所有者引导回客户端之前，授权服务器对资源所有者进行身份验证并获得授权。 因为资源所有者仅通过授权服务器进行身份验证，所以资源所有者的凭据永远不会与客户端共享。

授权代码提供了一些重要的安全益处，例如对客户端进行身份验证的能力，以及将访问令牌直接传输到客户端的过程，而无需将其传递给资源所有者的用户代理并可能将其暴露给其他人，包括 资源所有者。

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.

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.

1.3.2 隐式授权（Implicit）

隐式授权是简化的授权代码流程，该流程针对使用JavaScript之类的脚本语言在浏览器中实现的客户端进行了优化。 在隐式流程中，不是向客户端颁发授权代码，而是直接向客户端颁发访问令牌（作为资源所有者授权的结果）。 授予类型是隐式的，因为没有颁发中间凭证（例如授权码）（以后用于获取访问令牌）。

在隐式授予流程中颁发访问令牌时，授权服务器不会对客户端进行身份验证。 在某些情况下，可以通过用于将访问令牌传递给客户端的重定向URI验证客户端身份。 访问令牌可以向资源所有者或其他具有资源所有者的用户代理访问权限的应用程序公开。

隐式授予提高了某些客户端（例如，实现为浏览器内应用程序的客户端）的响应能力和效率，因为它减少了获取访问令牌所需的往返次数。 但是，应该权衡此便利性与使用隐式授予的安全隐患，例如在10.3和10.16节中描述的隐式授予，尤其是在授权码授予类型可用时。

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(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.

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.

1.3.3 资源所有者密码凭据（Resource Owner Password Credentials）

资源所有者密码凭据（即用户名和密码）可以直接用作授权许可来获取访问令牌。 仅当资源所有者和客户端之间存在高度信任（例如，客户端是设备操作系统或高特权应用程序的一部分）并且其他授权授予类型不可用时，才应使用凭据（ 例如授权码）。

尽管此授权类型需要客户端直接访问资源所有者凭据，但资源所有者凭据仅用于单个请求并交换为访问令牌。 通过将凭据与长期访问令牌或刷新令牌交换，此授权类型可以消除客户端存储资源所有者凭据以备将来使用的需要。

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.

1.3.4 客户端凭证（ Client Credentials ）

当授权范围限于客户端控制下的受保护资源或事先与授权服务器商定的受保护资源时客户端凭据可以被用作为一种授权许可。通常，当客户端代表自己（客户端也是资源所有者）行动或基于先前与授权服务器一起安排的授权请求访问受保护资源时，客户端凭据将用作授权授予。

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.

1.4 访问令牌（Access Token）

访问令牌是用于访问受保护资源的凭据。 访问令牌是一个字符串，表示颁发给客户端的授权。 该字符串通常对客户端不透明。 令牌代表特定的访问范围和持续时间，由资源所有者授予，并由资源服务器和授权服务器强制执行。

令牌可以表示用于检索授权信息的标识符，或者可以以可验证的方式自包含授权信息（即，由一些数据和签名组成的令牌字符串）。 为了让客户端使用令牌，可能需要额外的身份验证凭据，这超出了本规范的范围。

访问令牌提供了一个抽象层，用资源服务器可以理解的单个令牌替换了不同的授权结构（例如，用户名和密码）。这种抽象使发出的访问令牌比用于获得访问令牌的授权授予更具限制性，并且消除了资源服务器了解各种身份验证方法的需求。

根据资源服务器安全性要求，访问令牌可以具有不同的格式，结构和使用方法（例如，密码属性）。访问令牌属性和用于访问受保护资源的方法超出了本规范的范围，并且由诸如[RFC6750]之类的配套规范定义。

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].

1.5 刷新令牌（Refresh Token）

刷新令牌是用于获取访问令牌的凭据。 授权服务器将刷新令牌发布给客户端，并在当前访问令牌变得无效或过期时用于获取新的访问令牌，或者用于获取范围相同或范围较小的其他访问令牌（访问令牌的生存期可能较短，并且 少于资源所有者授权的权限）。 授权服务器可以决定是否发出刷新令牌。 如果授权服务器发出刷新令牌，则在发出访问令牌时将其包括在内（即，图1中的步骤（D））。

刷新令牌是一个字符串，代表资源所有者授予客户端的授权。 该字符串通常对客户端是不透明的。 令牌表示用于检索授权信息的标识符。 与访问令牌不同，刷新令牌仅用于授权服务器，并且永远不会发送到资源服务器。

图2所示的流程包括以下步骤：
（A）客户端通过与授权服务器进行身份验证并提供授权授权来请求访问令牌。
（B）授权服务器对客户端进行身份验证并验证授权授权，如果有效，则颁发访问令牌和刷新令牌。
（C）客户端通过提供访问令牌向资源服务器发出受保护的资源请求。
（D）资源服务器验证访问令牌，如果有效，则服务该请求。
（E）重复步骤（C）和（D），直到访问令牌过期。如果客户端知道访问令牌已过期，则跳至步骤（G）;否则，它将发出另一个受保护的资源请求。
（F）由于访问令牌无效，因此资源服务器返回无效令牌错误。
（G）客户端通过与授权服务器进行身份验证并提供刷新令牌来请求新的访问令牌。客户端身份验证要求基于客户端类型和授权服务器策略。
（H）授权服务器对客户端进行身份验证并验证刷新令牌，如果有效，则颁发新的访问令牌（以及可选的新的刷新令牌）。
步骤（C），（D），（E）和（F）在本规范的范围之外，如第7节所述。

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).

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.

The flow illustrated in Figure 2 includes the following steps: (A) The client requests an access token by authenticating with the authorization server and presenting an authorization grant. (B) The authorization server authenticates the client and validates the authorization grant, and if valid, issues an access token and a refresh token. (C) The client makes a protected resource request to the resource server by presenting the access token. (D) The resource server validates the access token, and if valid, serves the request. (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. (F) Since the access token is invalid, the resource server returns an invalid token error. (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. (H) The authorization server authenticates the client and validate the refresh token, and if valid, issues a new access token (and,optionally, a new refresh token). Steps (C), (D), (E), and (F) are outside the scope of this specification, as described in Section 7.

1.6 TLS版本（TLS version）

每当本规范使用安全传输层协议（TLS）时，TLS的适当版本都会根据广泛的部署和已知的安全漏洞而随时间变化。 在撰写本文时，TLS版本1.2 [RFC5246]是最新版本，但是其部署基础非常有限，可能无法立即用于实施。 TLS版本1.0 [RFC2246]是部署最广泛的版本，将提供最广泛的互操作性。
实现也可以支持其他满足其安全要求的传输层安全机制。

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. Implementations MAY also support additional transport-layer security mechanisms that meet their security requirements.

1.7 HTTP 重定向（HTTP Redirections）

该规范广泛使用了HTTP重定向，在该重定向中，客户端或授权服务器将资源所有者的用户代理定向到另一个目标。 尽管本规范中的示例显示了HTTP 302状态码的使用，但是允许通过用户代理使用的任何其他方法来完成此重定向，并且将其视为实现细节。

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.

1.8 互操作性（Interoperability）

OAuth 2.0提供了具有良好定义的安全属性的丰富授权框架。 但是，作为一个具有许多可选组件的丰富且高度可扩展的框架，此规范可能会产生各种不可互操作的实现。

此外，该规范还保留了一些必需的部分或全部未定义的组件(例如，客户端注册、授权服务器功能、端点发现)。如果没有这些组件，客户端必须针对特定的授权服务器和资源服务器手动和专门配置，以实现互操作。

这个框架的设计带有明确的期望，即未来的工作将定义规范性的概要文件和必要的扩展，以实现完全的web规模的互操作性。

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.

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.

1.9 符号约定（Notational Conventions）

本规范中的关键词“必须”、“必须”、“必需”、“应当”、“不应当”、“建议”、“可能”和“可选”的解释见[RFC2119]。

该规范使用了[RFC5234]的增强的Backus-Naur形式(ABNF)符号。此外，规则URI-引用包含在“统一资源标识符(URI):通用语法”[RFC3986]中。

某些与安全相关的术语应按照[RFC4949]中定义的意义来理解。这些术语包括但不限于:“攻击”、“认证”、“授权”、“证书”、“机密性”、“凭证”、“加密”、“身份”、“签名”、“签名”、“信任”、“验证”和“验证”。

除非另有说明，所有协议参数名称和值都是区分大小写的。

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].

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].

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”.

Unless otherwise noted, all the protocol parameter names and values are case sensitive.

2. 客户端注册（ Client Registration）

在启动协议之前，客户端向授权服务器注册。 客户端在授权服务器上进行注册的方式超出了本规范的范围，但通常涉及最终用户与HTML注册表格的交互。

客户端注册不需要客户端和授权服务器之间的直接交互。 当授权服务器支持时，注册可以依靠其他方式建立信任并获得所需的客户端属性（例如，重定向URI，客户端类型）。 例如，可以使用自行发出或第三方发出的声明来完成注册，也可以使用授权服务器使用受信任的通道执行客户端发现来完成注册。

注册客户端时，客户端开发人员应：

• 按照第2.1节所述指定客户端类型，
• 提供第3.1.2节中所述的客户端重定向URI，并
• 包括授权服务器所需的任何其他信息（例如，应用程序名称，网站，说明，徽标图片，接受法律条款）。

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.

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.

When registering a client, the client developer SHALL:

• specify the client type as described in Section 2.1,
• provide its client redirection URIs as described in Section 3.1.2, and
• include any other information required by the authorization server(e.g., application name, website, description, logo image, the acceptance of legal terms).

2.1 客户端类型（Client Types）

OAuth根据客户端对授权服务器进行安全身份验证的能力（即维护客户端凭据的机密性的能力），定义了两种客户端类型：

• 保密confidential

能够维护其凭证机密性的客户端(例如，在安全服务器上实现的客户端，对客户端凭证的访问受到限制)，或能够使用其他方法进行安全客户端身份验证的客户端。

• 公共public

客户端无法维护其凭证的机密性(例如，在资源所有者使用的设备上执行的客户端，如已安装的本地应用程序或基于web浏览器的应用程序)，并且无法通过任何其他方式进行安全的客户端身份验证。

客户端类型的指定基于授权服务器对安全身份验证的定义及其可接受的客户端凭据公开级别。 授权服务器不应该对客户端类型做任何假设。
客户端可以被实现为组件的分布式集合，每个组件具有不同的客户端类型和安全性上下文（例如，具有基于机密服务器的组件和基于公共浏览器的组件两者的分布式客户端）。 如果授权服务器不为此类客户端提供支持或不提供有关其注册的指导，则客户端应将每个组件注册为单独的客户端。

该规范是围绕以下客户端配置文件设计的：

• Web应用程序

  Web应用程序是在Web服务器上运行的机密客户端。资源所有者通过在资源所有者使用的设备上的用户代理中呈现的HTML用户界面访问客户端。客户端凭据以及颁发给客户端的任何访问令牌都存储在Web服务器上，并且资源所有者无法访问或访问。

• 基于用户代理的应用

  基于用户代理的应用程序是一个公共客户端，其中客户端代码是从Web服务器下载的，并在资源所有者使用的设备上的用户代理（例如Web浏览器）中执行。协议数据和凭据易于资源所有者访问（并且经常可见）。由于此类应用程序驻留在用户代理内，因此它们在请求授权时可以无缝使用用户代理功能。

• 本机应用

  本机应用程序是在资源所有者使用的设备上安装并执行的公共客户端。协议数据和凭据可供资源所有者访问。假定可以提取应用程序中包含的任何客户端身份验证凭据。另一方面，动态颁发的凭据（例如访问令牌或刷新令牌）可以收到可接受的保护级别。至少，应保护这些凭据不受应用程序可能与之交互的敌对服务器的攻击。在某些平台上，可以保护这些凭据免受驻留在同一设备上的其他应用程序的攻击。

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):

• 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.

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.

• 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.

• 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.

2.2 客户端标识（ Client Identifier）

授权服务器向注册的客户端发出客户端标识符——表示客户端提供的注册信息的唯一字符串。客户标识符不是秘密;它是公开给资源所有者的，不能单独用于客户端身份验证。客户端标识符对于授权服务器是唯一的。
此规范未定义客户端标识符字符串大小。客户端应该避免假设标识符的大小。授权服务器应该记录它所发出的任何标识符的大小。

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.

2.3 客户端身份认证（ Client Authentication ）

如果客户端类型是机密的，客户端和授权服务器将建立适合授权服务器安全需求的客户端身份验证方法。授权服务器可以接受满足其安全需求的任何形式的客户端身份验证。

机密客户端通常颁发(或建立)一组客户端凭据，用于与授权服务器进行身份验证(例如，密码、公钥/私钥对)。

授权服务器可以与公共客户端建立客户端身份验证方法。但是，授权服务器不能依赖公共客户端身份验证来标识客户端。

客户端在每个请求中不得使用多种身份验证方法。

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.

2.3.1. 客户端密码（Client Password）

拥有客户端密码的客户端可以使用 [RFC2617] 中定义的 HTTP 基本身份验证方案与授权服务器进行身份验证。 客户端标识符使用附录 B 中的“application/x-www-form-urlencoded”编码算法进行编码，编码后的值用作用户名； 客户端密码使用相同的算法进行编码并用作密码。 授权服务器必须支持 HTTP 基本身份验证方案，用于对已发布客户端密码的客户端进行身份验证。

例如(为了显示的目的使用额外的换行符):
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3

或者，授权服务器可以使用以下参数支持在请求正文中包括客户端证书：
client_id
需要。 在第2.2节所述的注册过程中向客户端发布的客户端标识符。
client_secret
需要。 客户机密。 如果客户秘密是一个空字符串，则客户可以忽略该参数。

不建议使用两个参数在请求正文中包含客户端凭据，并且应仅限于无法直接利用HTTP Basic身份验证方案（或其他基于密码的HTTP身份验证方案）的客户端。 参数只能在请求正文中传输，并且不得包含在请求URI中。

例如，使用主体参数（带有额外的换行符仅用于显示目的）刷新访问令牌的请求（第6节）：
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

 grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA<br />     &**client_id**=s6BhdRkqt3&**client_secret**=7Fjfp0ZBr1KtDRbnfVdmIw

使用密码身份验证发送请求时，授权服务器务必要求使用第1.6节所述的TLS。
由于此客户端身份验证方法涉及密码，因此授权服务器务必保护使用该密码的任何端点免受暴力攻击。

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.

For example (with extra line breaks for display purposes only): 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. 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.

For example, a request to refresh an access token (Section 6) using the body parameters (with extra line breaks for display purposes only):

 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
 The authorization server MUST require the use of TLS as described in Section 1.6 when sending requests using password authentication.

Since this client authentication method involves a password, the authorization server MUST protect any endpoint utilizing it against brute force attacks.

2.3.2. 其他身份验证方法（Other Authentication Methods）

授权服务器可以支持与其安全要求相匹配的任何合适的HTTP认证方案。 当使用其他认证方法时，授权服务器必须定义客户标识符（注册记录）和认证方案之间的映射。

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.

2.4 未注册客户端（Unregistered Clients）

本规范并不排除使用未注册的客户端。但是，使用此类客户端超出了本规范的范围，并且需要进行额外的安全分析并检查其互操作性影响。

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.

3. 协议端点（Protocol Endpoints）

授权过程利用两个授权服务器端点(HTTP资源):

• 授权端点——客户端用于通过用户代理重定向从资源所有者获得授权。
• 令牌端点——客户端用于将授权授予与访问令牌交换，通常与客户端身份验证一起使用。

以及一个客户端端点:

• 重定向端点——授权服务器使用它通过资源所有者用户代理向客户端返回包含授权凭据的响应。

并非每种授权授予类型都同时使用两个端点。 扩展授权类型可以根据需要定义其他端点。

The authorization process utilizes two authorization server endpoints(HTTP resources):

• Authorization endpoint - used by the client to obtain authorization from the resource owner via user-agent redirection.
• Token endpoint - used by the client to exchange an authorization grant for an access token, typically with client authentication.

As well as one client endpoint:

• Redirection endpoint - used by the authorization server to return responses containing authorization credentials to the client via the resource owner user-agent.

Not every authorization grant type utilizes both endpoints. Extension grant types MAY define additional endpoints as needed.

3.1 授权端点（Authorization Endpoint）

授权端点用于与资源所有者交互并获得授权。 授权服务器必须首先验证资源所有者的身份。 授权服务器验证资源所有者的方式（例如，用户名和密码登录、会话 cookie）超出了本规范的范围。

客户端获取授权端点location的方法超出了本规范的范围，但是该location通常在服务文档中提供。

端点URI可能包括一个“application/x-www-form-urlencoded”格式的查询组件(见附录B) ([RFC3986]节3.4)，当添加额外的查询参数时必须保留该组件。端点URI必须不包含片段组件。

由于对授权端点的请求会导致用户身份验证和明文凭据的传输（在HTTP响应中），因此，在向授权端点发送请求时，授权服务器务必要求使用TLS（如第1.6节所述）。

授权服务器必须支持对授权端点使用HTTP“ GET”方法[RFC2616]，并且还可以支持使用“ POST”方法。
发送的没有值的参数必须被视为请求中已省略的参数。 授权服务器必须忽略无法识别的请求参数。 请求和响应参数不得超过一次。

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.

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.

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.

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. 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.

3.1.1. 响应类型（Response Type）

授权端点由授权码授予类型和隐式授予类型流使用。 客户端使用以下参数将所需的授予类型通知授权服务器：
response_type
必需的。该值必须是4.1.1节所述请求授权码的“code”之一，或4.2.1节所述请求访问令牌(隐式授权)的“token”之一，或8.4节所述的注册扩展值之一。
授权码模式示例：
https://b.com/oauth/authorize? response_type=code& client_id=CLIENT_ID& redirect_uri=CALLBACK_URL& scope=read
隐式模式示例：
https://b.com/oauth/authorize? response_type=token& client_id=CLIENT_ID& redirect_uri=CALLBACK_URL& scope=read

扩展响应类型可以包含以空格分隔的（％x20）值列表，其中值的顺序无关紧要（例如，响应类型“ a b”与“ ba a”相同）。 这种复合响应类型的含义由它们各自的规范定义。

如果授权请求缺少“response_type”参数，或者响应类型不能理解，授权服务器必须返回一个错误响应，如4.1.2.1节所述。

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.

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.

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.

3.1.2. 重定向端点（Redirection Endpoint）

在完成与资源所有者的交互之后，授权服务器将资源所有者的用户代理定向回客户端。 授权服务器将用户代理重定向到客户端在注册过程中或发出授权请求时与授权服务器先前建立的客户端重定向端点。

重定向端点URI必须是[RFC3986] 4.3节所定义的绝对URI。 端点URI可以包括一个格式为“ application / x-www-form-urlencoded”（按附录B）的查询组件（[RFC3986] 3.4节），在添加附加查询参数时必须保留该组件。 端点URI不得包含片段组件。

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.

3.1.2.1. 端点请求机密性 （Endpoint Request Confidentiality）

当请求的响应类型是“code”或“token”，或者重定向请求将导致在开放网络上传输敏感凭据时，重定向端点应该要求使用1.6节中描述的TLS。此规范并不强制使用TLS，因为在撰写本文时，要求客户端部署TLS是许多客户端开发人员面临的一个重大障碍。如果TLS不可用，授权服务器应该在重定向之前警告资源所有者端点不安全(例如，在授权请求期间显示一条消息)。

缺乏传输层安全性可能严重影响客户端的安全性以及授权访问的受保护资源。 当授权过程用作客户端委托的最终用户身份验证的一种形式时，传输层安全性的使用尤其重要（例如，第三方登录服务）。

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).

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).

3.1.2.2. 注册要求（Registration Requirements）

授权服务器必须要求以下客户端注册它们的重定向端点:

• 公共客户端
• 使用隐式授予类型的机密客户端

授权服务器应要求所有客户端在使用授权端点之前注册其重定向端点。

授权服务器应该要求客户端提供完整的重定向URI（客户端可以使用“ state”请求参数来实现每个请求的定制）。 如果无法要求注册完整的重定向URI，则授权服务器应要求注册URI方案，权限和路径（允许客户端在请求授权时仅动态更改重定向URI的查询组件）。

授权服务器可能允许客户端注册多个重定向端点。
缺乏重定向URI注册要求可以使攻击者使用授权端点作为开放的重定向，如10.15节所述。

The authorization server MUST require the following clients to register their redirection endpoint:

• Public clients
• Confidential clients utilizing the implicit grant type.

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).

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.

3.1.2.3. 动态配置（Dynamic Configuration）

如果注册了多个重定向URI，如果只注册了重定向URI的一部分，或者没有注册重定向URI，客户端必须使用“redirect_uri”请求参数在授权请求中包含一个重定向URI。

当在授权请求中包含重定向URI时，如果注册了任何重定向URI，授权服务器必须将接收到的值与[RFC3986]第6节定义的至少一个已注册重定向URI(或URI组件)进行比较和匹配。如果客户端注册包含完整的重定向URI，授权服务器必须使用[RFC3986] 6.2.1节定义的简单字符串比较两个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.

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.

3.1.2.4. 无效端点（Invalid Endpoint）

如果授权请求由于丢失、无效或不匹配重定向URI而导致验证失败，授权服务器应将错误通知资源所有者，并且一定不能自动将用户代理重定向到无效重定向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.

3.1.2.5. 端点内容（Endpoint Content）

对客户端端点的重定向请求通常会导致HTML文档响应，由用户代理处理。如果直接将HTML响应作为重定向请求的结果提供，则HTML文档中包含的任何脚本都将执行，并具有对重定向URI及其包含的凭据的完全访问权。

客户端不应在重定向端点响应中包含任何第三方脚本(例如，第三方分析、社交插件、广告网络)。相反，它应该从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.

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.

3.2 令牌端点（Token Endpoint）

令牌端点由客户端使用，通过提供其授权授予或刷新令牌来获得访问令牌。令牌端点与每个授权批准一起使用，但隐式授权类型除外(因为访问令牌是直接颁发的)。

客户端获取令牌端点location的方法超出了本规范的范围，但是该位置通常在服务文档中提供。

端点URI可能包括一个“application/x-www-form-urlencoded”格式的查询组件(见附录B) ([RFC3986]节3.4)，当添加额外的查询参数时必须保留该组件。端点URI必须不包含片段组件。

由于对令牌端点的请求会导致用户身份验证和明文凭据的传输（在HTTP响应中），因此，在向令牌端点发送请求时，授权服务器务必要求使用TLS（如第1.6节所述）。

发出访问令牌请求时，客户端必须使用HTTP“ POST”方法。

发送的没有值的参数必须被视为请求中已省略的参数。 授权服务器必须忽略无法识别的请求参数。 请求和响应参数不得超过一次。

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.

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 token endpoint.

The client MUST use the HTTP “POST“ method when making access token requests.

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.

3.2.1. 客户端认证（Client Authentication）

当向令牌端点发出请求时，机密客户端或其他客户端发出的客户端凭据必须与授权服务器进行身份验证，如第2.3节所述。客户端认证用于:

• 强制将刷新令牌和授权码绑定到颁发它们的客户端。 当授权码通过不安全的通道传输到重定向端点或重定向URI尚未完全注册时，客户端身份验证至关重要。
• 通过禁用客户端或更改其凭据从被盗用的客户端中恢复，从而防止攻击者滥用被盗的刷新令牌。 更改单个客户端凭据集比撤销整个刷新令牌集要快得多。
• 实施身份验证管理最佳实践，这需要定期进行凭据轮换。 整套刷新令牌的轮换可能具有挑战性，而单套客户端凭据的轮换则要容易得多。

当向令牌端点发送请求时，客户端可以使用“client_id”请求参数来标识自身。在对令牌端点的“authorization_code”“grant_type”请求中，未经身份验证的客户端必须发送其“client_id”，以防止自己无意中接受了针对具有不同“client_id”的客户端的代码。这可以保护客户端不被替换身份验证代码。(它不为受保护的资源提供额外的安全性。)

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:

• 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
• 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.
• 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.

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.)

3.3 访问令牌的范围（Access Token Scope）

授权和令牌端点允许客户端使用“scope”请求参数指定访问请求的范围。然后，授权服务器使用“scope”响应参数将发出的访问令牌的范围来通知客户端。

scope参数的值表示为一组空格分隔、区分大小写的字符串。这些字符串由授权服务器定义。如果值包含多个空格分隔的字符串，则它们的顺序无关紧要，每个字符串都会向请求的范围添加一个额外的访问范围。
scope = scope-token ( SP scope-token )
scope-token = 1( %x21 / %x23-5B / %x5D-7E )

根据授权服务器策略或资源所有者的指示，授权服务器可以完全或部分忽略客户端请求的范围。 如果发布的访问令牌作用域与客户端请求的访问令牌作用域不同，则授权服务器务必包含“scope”响应参数，以将实际授予的作用域通知客户端。

如果客户端在请求授权时省略了scope参数，则授权服务器必须使用预定义的默认值处理请求，或者使指示无效范围的请求失败。 授权服务器应记录其范围要求和默认值（如果已定义）。

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.

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-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.

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).

4. 获得授权（Obtaining Authorization）

为了请求访问令牌，客户端从资源所有者获取授权。 授权以授权许可的形式表示，客户端使用该授权许可来请求访问令牌。 OAuth定义了四种授予类型：授权码，隐式，资源所有者密码凭据和客户端凭据。 它还提供了用于定义其他授予类型的扩展机制。

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.

4.1 授权码模式授权（Authorization Code Grant）

授权码授予类型用于获取访问令牌和刷新令牌，并且已针对机密客户端进行了优化。 由于这是基于重定向的流程，因此客户端必须能够与资源所有者的用户代理（通常是Web浏览器）进行交互，并能够（通过重定向）接收来自授权服务器的传入请求。

注意:说明步骤(A)、(B)和(C)的行被分解当它们通过用户代理时分为两部分。

图3所示的流程包括以下步骤：
（A）客户端通过将资源所有者的用户代理定向到授权端点来启动流程。客户端包括其客户端标识符，请求的范围，本地状态和重定向URI，一旦授予（或拒绝）访问权限，授权服务器便会将用户代理发送回该重定向URI。
（B）授权服务器（通过用户代理）对资源所有者进行身份验证，并确定资源所有者是授予还是拒绝客户端的访问请求。
（C）假设资源所有者授予访问权限，授权服务器使用先前提供的重定向URI（在请求中或在客户端注册期间）将用户代理重定向回客户端。重定向URI包括授权码和客户端之前提供的任何本地状态。
（D）客户端通过包括上一步中收到的授权码，从授权服务器的令牌端点请求访问令牌。发出请求时，客户端向授权服务器进行身份验证。客户端包括用于获取验证授权码的重定向URI。
（E）授权服务器对客户端进行身份验证，验证授权码，并确保在步骤（C）中接收到的重定向URI与用于重定向客户端的URI匹配。如果有效，授权服务器将以访问令牌和（可选）刷新令牌进行响应。

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.

The flow illustrated in Figure 3 includes the following steps: (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). (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. (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. (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. (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.

4.1.1. 授权请求（Authorization Request）

客户端通过使用“application/x-www-form-urlencoded”格式向授权端点URI的查询组件添加以下参数来构建请求URI，详见附录B:
response_type
需要。 值必须设置为“code”。
client_id
需要。 客户标识符，如第2.2节所述。
redirect_uri
可选的。 如3.1.2节所述。
scope
可选的。 访问请求的范围，如第3.3节所述。
state
推荐的。 客户端用来维持请求和回调之间状态的不透明值。 当将用户代理重定向回客户端时，授权服务器将包含此值。 如第10.12节所述，参数应用于防止跨站点请求伪造。

客户端使用HTTP重定向响应或通过用户代理可用的其他方式将资源所有者定向到构造的URI。

例如，客户端指示用户代理使用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

授权服务器将验证请求，以确保所有必需参数都存在且有效。 如果请求有效，则授权服务器对资源所有者进行身份验证并获得授权决定（通过询问资源所有者或通过其他方式建立批准）。

建立决策后，授权服务器使用HTTP重定向响应或通过用户代理可用的其他方式将用户代理定向到提供的客户端重定向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: response_type REQUIRED. Value MUST be set to “code“. client_id REQUIRED. The client identifier as described in Section 2.2. redirect_uri OPTIONAL. As described in Section 3.1.2. scope OPTIONAL. The scope of the access request as described by Section 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.

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.

For example, the client directs the user-agent to make the following HTTP request using TLS (with extra line breaks for display purposes only): 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.

4.1.2. 授权响应（Authorization Response）

如果资源所有者授予访问请求，授权服务器发出授权代码，并通过使用附录B中的“application/x-www-form-urlencoded”格式向重定向URI的查询组件添加以下参数，将其交付给客户端:
code
必需的。授权服务器生成的授权代码。授权代码必须在发布后不久过期，以减轻泄漏的风险。建议最大授权代码生存期为10分钟。客户端不能多次使用授权代码。如果某个授权代码被多次使用，授权服务器必须拒绝请求，并(在可能的情况下)撤销之前基于该授权代码发出的所有令牌。授权代码绑定到客户端标识符和重定向URI。
state
如果客户端授权请求中存在“state”参数，则需要。从客户端接收到的确切值。

例如，授权服务器通过发送以下HTTP响应来重定向用户代理：
HTTP/1.1 302 Found
Location:
&state=xyz

客户端必须忽略无法识别的响应参数。 该规范未定义授权码字符串的大小。 客户应避免对代码值大小进行假设。 授权服务器应记录其发出的任何值的大小。

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: 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 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. state REQUIRED if the “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/1.1 302 Found
 Location: 
           &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.

4.1.2.1. 错误响应（Error Response）

如果由于丢失，无效或不匹配的重定向URI而导致请求失败，或者客户端标识符丢失或无效，则授权服务器应将错误通知资源所有者，并且不得将用户代理自动重定向到无效的重定向 URI。

如果资源所有者拒绝访问请求，或者请求由于丢失或无效的重定向URI以外的其他原因而失败，则授权服务器通过使用“ application / x- www-form-urlencoded“格式，请参阅附录B：
error
需要。 来自以下内容的单个ASCII [USASCII]错误代码：
invalid_request
该请求缺少必需的参数，包含无效的参数值，多次包含一个参数，或者格式错误。
unauthorized_client
客户端无权使用此方法请求授权码。
access_denied
资源所有者或授权服务器拒绝了该请求。
unsupported_response_type
授权服务器不支持使用此方法获取授权码。
invalid_scope
请求的范围无效，未知或格式错误。
server_error
授权服务器遇到意外情况，阻止其执行请求。（需要此错误代码，因为500内部服务器错误HTTP状态代码无法通过HTTP重定向返回给客户端。）
temporarily_unavailable
由于服务器的暂时超载或维护，授权服务器当前无法处理该请求。 （由于无法通过HTTP重定向将503服务不可用HTTP状态代码返回给客户端，因此需要此错误代码。）
“错误”参数的值不得包含超出设置的％x20-21 /％x23-5B /％x5D-7E的字符。
error_description
可选的。提供额外信息的人类可读的ASCII [USASCII]文本，用于帮助客户端开发人员理解发生的错误。”error_description”参数的值不能包含设置%x20-21 / %x23-5B / %x5D-7E之外的字符。
error_uri
可选的。标识带有错误信息的人类可读web页面的URI，用于向客户端开发人员提供关于错误的附加信息。“error_uri”参数的值必须符合uri引用语法，因此不能包含集合%x21 / %x23-5B / %x5D-7E之外的字符。
state
必需的。如果客户端授权请求中存在“state”参数。从客户端接收到的确切值。

例如，授权服务器通过发送以下HTTP响应来重定向用户代理：
HTTP/1.1 302 Found
Location: https://client.example.com/cb?error=access_denied&state=xyz

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.

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: error REQUIRED. A single ASCII [USASCII] error code from the following: 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. 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. invalid_scope The requested scope is invalid, unknown, or malformed. 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.) 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.) Values for the “error” parameter MUST NOT include characters outside the set %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. 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. 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/1.1 302 Found Location: https://client.example.com/cb?error=access_denied&state=xyz

4.1.3. 访问令牌请求（Access Token Request）

客户端向令牌端点发出一个请求，使用附录B中的“application/x-www-form-urlencoded”格式，在HTTP请求实体-body中使用UTF-8字符编码发送以下参数:
grant_type
必需的。值必须设置为“authorization_code”。
code
必需的。从授权服务器接收的授权代码。
redirect_uri
必需的。如果“redirect_uri”参数如4.1.1节所述包含在授权请求中，且它们的值必须相同。
client_id
必需的。如果客户端没有使用3.2.1节所述的授权服务器进行身份验证。

如果客户端类型是机密的，或者客户端获得了客户端凭证(或分配了其他身份验证要求)，客户端必须按照3.2.1节所述使用授权服务器进行身份验证。

例如，客户端使用TLS发出以下HTTP请求（带有额外的换行符仅用于显示目的）：
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<br />     &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

授权服务器必须：

• 要求对机密客户端或任何获得客户端凭据（或具有其他身份验证要求）的客户端进行客户端身份验证，
• 如果包括客户端身份验证，则对客户端进行身份验证，
• 确保将授权码发布给已认证的机密客户端，或者如果客户端是公开的，则确保将代码发布给请求中的“ client_id”，
• 验证授权码有效，并且
• 如果在第4.1.1节中所述的初始授权请求中包含了“ redirect_uri”参数，请确保存在“ redirect_uri”参数，如果包含，请确保其值相同。

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: 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. client_id REQUIRED. If the client is not authenticating with the authorization server as described in Section

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.

For example, the client makes the following HTTP request using TLS (with extra line breaks for display purposes only): 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

The authorization server MUST:

• require client authentication for confidential clients or for any client that was issued client credentials (or with other authentication requirements),
• authenticate the client if client authentication is included,
• 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,
• verify that the authorization code is valid, and
• 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.

4.1.4. 访问令牌响应（Access Token Response）

如果访问令牌请求是有效且已授权的，则授权服务器将发布访问令牌和可选的刷新令牌，如5.1节所述。 如果请求客户端身份验证失败或无效，则授权服务器将返回错误响应，如5.2节所述。

一个成功响应示例：

 HTTP/1.1 200 OK<br />     Content-Type: application/json;charset=UTF-8<br />     Cache-Control: no-store<br />     Pragma: no-cache
 {<br />       "access_token":"2YotnFZFEjr1zCsicMWpAA",<br />       "token_type":"example",<br />       "expires_in":3600,<br />       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",<br />       "example_parameter":"example_value"<br />     }

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.

An example successful response:

 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"
 }

4.2 隐式授权（Implicit Grant）

隐式授予类型用于获取访问令牌(它不支持发布刷新令牌)，并针对已知操作特定重定向URI的公共客户端进行了优化。这些客户机通常在浏览器中使用脚本语言(如JavaScript)实现。

由于这是基于重定向的流程，因此客户端必须能够与资源所有者的用户代理（通常是Web浏览器）进行交互，并且能够（通过重定向）接收来自授权服务器的传入请求。

隐式授予类型不包括客户端身份验证，而是依赖于资源所有者的存在和重定向URI的注册。 由于访问令牌已编码到重定向URI中，因此它可能会暴露给资源所有者和驻留在同一设备上的其他应用程序。

图4所示的流程包括以下步骤：
（A）客户端通过将资源所有者的用户代理定向到授权端点来启动流程。 客户端包括其客户端标识符，请求的范围，本地状态和重定向URI，一旦授予（或拒绝）访问权限，授权服务器便会将用户代理发送回该重定向URI。

（B）授权服务器（通过用户代理）对资源所有者进行身份验证，并确定资源所有者是授予还是拒绝客户端的访问请求。

（C）假设资源所有者授予访问权限，授权服务器使用前面提供的重定向URI将用户代理重定向回客户端。 重定向URI在URI片段中包含访问令牌。

(D)用户代理遵循重定向指令，通过向web托管的客户端资源发出请求(不包括每个[RFC2616]的片段)。user-agent在本地保留片段信息。

(E) web托管的客户端资源返回一个web页面(通常是一个带有嵌入脚本的HTML文档)，它能够访问完整的重定向URI，包括由用户代理保留的片段，并提取片段中包含的访问令牌(和其他参数)。

（F）用户代理在本地执行由Web托管的客户端资源提供的脚本，该脚本提取访问令牌。

（G）用户代理将访问令牌传递给客户端。

有关使用隐式授予的背景信息，请参见第1.3.2和9节。
有关使用隐式授予的重要安全注意事项，请参见10.3和10.16节。

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.

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.

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.

The flow illustrated in Figure 4 includes the following steps: (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).

(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.

(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.

(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.

(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.

(F) The user-agent executes the script provided by the web-hosted client resource locally, which extracts the access token.

(G) The user-agent passes the access token to the client.

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.

4.2.1. 授权请求（Authorization Request）

根据附录 B，客户端通过使用“application/x-www-form-urlencoded”格式将以下参数添加到授权端点 URI 的查询组件来构建请求 URI：
response_type
必须. 值设置为”token“.
client_id
必须. 2.2 节中描述的客户端标识符.
redirect_uri
可选. 如第 3.1.2 节所述。
scope
可选. 访问请求的范围描述为第 3.3 节。
state
推荐. 客户端用于维护请求和回调之间的状态的不透明值。 授权服务器在将用户代理重定向回客户端时包含此值。 该参数应该用于防止跨站点请求伪造，如第 10.12 节所述。

客户端使用 HTTP 重定向响应或通过用户代理可用的其他方式将资源所有者定向到构造的 URI。

例如，客户端指示用户代理使用 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

授权服务器验证请求以确保所有必需的参数都存在且有效。 授权服务器必须验证它将访问令牌重定向到的重定向 URI 是否与客户端注册的重定向 URI 匹配，如第 3.1.2 节所述。

如果请求有效，授权服务器对资源所有者进行身份验证并获得授权决定（通过询问资源所有者或通过其他方式建立批准）。

确定决定后，授权服务器使用 HTTP 重定向响应或通过用户代理可用的其他方式将用户代理定向到提供的客户端重定向 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: response_type REQUIRED. Value MUST be set to “token“. client_id REQUIRED. The client identifier as described in Section 2.2. redirect_uri OPTIONAL. As described in Section 3.1.2. scope OPTIONAL. The scope of the access request as described by Section 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.

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.

For example, the client directs the user-agent to make the following HTTP request using TLS (with extra line breaks for display purposes only):

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.

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.

4.2.2. 访问令牌响应（Access Token Response）

如果资源所有者批准访问请求，则授权服务器发出访问令牌并将其传递给客户端，方法是使用“application/x-www-form-urlencoded”格式将以下参数添加到重定向 URI 的片段组件中， 根据附录 B：

access_token
必须. 授权服务器颁发的访问令牌。
token_type
必须. 发行的令牌类型如第 7.1 节。 值不区分大小写。
expires_in
推荐. 访问令牌的生命周期（以秒为单位）。 例如，值“3600”表示访问令牌将在响应生成后的一小时内到期。 如果省略，授权服务器应该通过其他方式提供过期时间或记录默认值。
scope
可选. if identical to the scope requested by the client;otherwise, REQUIRED. The scope of the access token as described by Section 3.3.
state
必须。如果客户端授权请求中存在“state”参数。 从客户端收到的确切值。

授权服务器不得发出刷新令牌。例如，授权服务器通过发送以下 HTTP 响应来重定向用户代理（带有仅用于显示目的的额外换行符）：

HTTP/1.1 302 Found Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA &state=xyz&token_type=example&expires_in=3600

开发人员应注意，某些用户代理不支持在 HTTP“Location”响应头字段中包含片段组件。 此类客户端将需要使用其他方法来重定向客户端而不是 3xx 重定向响应——例如，返回一个 HTML 页面，其中包含一个“continue”按钮，其中包含一个链接到重定向 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: access_token REQUIRED. The access token issued by the authorization server. token_type REQUIRED. The type of the token issued as described in Section 7.1. Value is case insensitive. 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. 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. state REQUIRED if the “state” parameter was present in the client authorization request. The exact value received from the client.

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/1.1 302 Found
 Location: [http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA](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.

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.

4.2.2.1. 错误响应（Error Response）

如果请求由于重定向 URI 丢失、无效或不匹配而失败，或者如果客户端标识符丢失或无效，授权服务器应该将错误通知资源所有者，并且不得自动将用户代理重定向到无效重定向 URI。
如果资源所有者拒绝访问请求，或者请求因重定向 URI 丢失或无效以外的原因而失败，则授权服务器通过使用“application/x-www-form-urlencoded”格式将以下参数添加到重定向 URI 的片段组件中来通知客户端， 根据附录 B：

error
必须. 来自以下的单个 ASCII [USASCII] 错误代码：
invalid_request
请求缺少必需的参数、包含无效的参数值、包含不止一次的参数或格式不正确。
unauthorized_client
客户端无权使用此方法请求访问令牌。
access_denied
资源所有者或授权服务器拒绝了请求。
unsupported_response_type
授权服务器不支持使用此方法获取访问令牌。
invalid_scope
请求的范围无效、未知或格式错误。
server_error
授权服务器遇到了阻止其完成请求的意外情况。（需要此错误代码是因为 500 Internal Server Error HTTP 状态代码无法通过 HTTP 重定向返回给客户端。）
temporarily_unavailable
由于服务器暂时过载或维护，授权服务器当前无法处理请求。 （需要此错误代码是因为无法通过 HTTP 重定向向客户端返回 503 Service Unavailable HTTP 状态代码。）
“错误”参数的值不得包含 %x20-21 / %x23-5B / %x5D-7E 集之外的字符。
error_description
可选. 提供附加信息的人类可读 ASCII [USASCII] 文本，用于帮助客户端开发人员了解发生的错误。“error_description”参数的值不得包含 %x20-21 / %x23-5B / % 集之外的字符 x5D-7E。
error_uri
可选. 一个 URI，用于标识带有错误信息的人类可读网页，用于向客户端开发人员提供有关错误的附加信息。 “error_uri”参数的值必须符合 URI 引用语法，因此不得包含 %x21 / %x23-5B / %x5D-7E 集之外的字符。
state
必须。如果客户端授权请求中存在“状态”参数。 从客户端收到的确切值。

例如，授权服务器通过以下方式重定向用户代理发送以下 HTTP 响应：

HTTP/1.1 302 Found Location: https://client.example.com/cb#error=access_denied&state=xyz

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.

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: error REQUIRED. A single ASCII [USASCII] error code from the following: 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. 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. invalid_scope The requested scope is invalid, unknown, or malformed. 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.) 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.)

     Values for the "error" parameter MUST NOT include characters outside the set %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. 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. 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/1.1 302 Found Location: https://client.example.com/cb#error=access_denied&state=xyz

4.3 资源所有者密码凭证授权（ Resource Owner Password Credentials Grant）

资源所有者密码凭据授予类型适用于资源所有者与客户端具有信任关系的情况，例如设备操作系统或高特权应用程序。 授权服务器在启用此授予类型时应格外小心，仅在其他流程不可行时才允许它。

此授予类型适用于能够获得资源所有者的凭据（用户名和密码，通常使用交互形式）的客户端。 通过将存储的凭据转换为访问令牌，它还可用于使用直接身份验证方案（例如HTTP基本或摘要身份验证）将现有客户端迁移到OAuth。

图 5 所示的流程包括以下步骤：
(A) 资源所有者向客户端提供其用户名和密码。
(B) 客户端通过包含从资源所有者收到的凭据，从授权服务器的令牌端点请求访问令牌。 发出请求时，客户端向授权服务器进行身份验证。
(C) 授权服务器对客户端进行身份验证并验证资源所有者凭据，如果有效，则颁发访问令牌。

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.

The flow illustrated in Figure 5 includes the following steps: (A) The resource owner provides the client with its username and password. (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. (C) The authorization server authenticates the client and validates the resource owner credentials, and if valid, issues an access token.

4.3.1. 授权请求和响应（Authorization Request and Response）

客户端获取资源所有者凭证的方法超出了本规范的范围。 一旦获得访问令牌，客户端必须丢弃凭证。

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.

4.3.2. 访问令牌请求（Access Token Request）

客户端通过使用附录 B 中的“application/x-www-form-urlencoded”格式添加以下参数向令牌端点发出请求，在 HTTP 请求实体正文中使用 UTF-8 字符编码：
grant_type
必须. 值必须设置为“password”。
username
必须. 资源所有者用户名。
password
必须. 资源所有者密码。
scope
可续. 访问请求的范围如第 3.3 节所述。

如果客户端类型是机密的，或者客户端获得了客户端凭据（或分配了其他身份验证要求），则客户端必须按照第 3.2.1 节中的描述向授权服务器进行身份验证。

例如，客户端使用传输层安全性发出以下 HTTP 请求（额外的换行符仅用于显示目的）：

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

授权服务器必须：

o 要求对**机密客户端或任何已颁发客户端凭据**（或具有其他身份验证要求）的客户端进行客户端身份验证，
o 如果包含客户端身份验证，则对客户端进行身份验证，以及
o 使用其现有的密码验证算法验证资源所有者的密码凭据。

由于此访问令牌请求使用资源所有者的密码，因此授权服务器必须保护端点免受暴力攻击（例如，使用速率限制或生成警报）。

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: 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.

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.

For example, the client makes the following HTTP request using transport-layer security (with extra line breaks for display purposes only):

 POST /token HTTP/1.1<br />     Host: server.example.com<br />     Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW<br />     Content-Type: application/x-www-form-urlencoded
 grant_type=password&username=johndoe&password=A3ddj3w<br />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 authenticate the client if client authentication is included, and

o validate the resource owner password credentials using its
existing password validation algorithm.

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).

4.3.3. 访问令牌响应（Access Token Response）

如果访问令牌请求有效并获得授权，则授权服务器发布访问令牌和可选的刷新令牌，如第 5.1 节所述。 如果请求客户端身份验证失败或无效，授权服务器将返回错误响应，如第 5.2 节所述。

成功响应示例：

 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"
 }

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.

An example successful response:

 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"
 }

4.4 客户端凭证授权（Client Credentials Grant）

客户端可以请求一个访问令牌只使用客户证书(或其他支持身份验证的手段)当客户端请求访问受保护的资源在其控制下,或者另一个资源所有者与授权服务器之前安排的方法(这是超出了本规范的范围)。

客户端证书授予类型必须只能由机密客户端使用。

图6所示的流程包括以下步骤：
（A）客户端通过授权服务器进行身份验证，并从令牌端点请求访问令牌。
（B）授权服务器对客户端进行身份验证，如果有效，则颁发访问令牌。

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.

The flow illustrated in Figure 6 includes the following steps: (A) The client authenticates with the authorization server and requests an access token from the token endpoint. (B) The authorization server authenticates the client, and if valid, issues an access token.

4.4.1. 授权请求和响应（Authorization Request and Response）

由于将客户端身份验证用作授权授予，因此不需要其他授权请求。

Since the client authentication is used as the authorization grant, no additional authorization request is needed.

4.4.2. 访问令牌请求（Access Token Request）

客户端向令牌端点发出请求，使用附录B中的“application/x-www-form-urlencoded”格式，在HTTP请求实体-body中使用UTF-8字符编码，添加以下参数:
grant_type
必需的。值必须设置为“client_credentials”。
scope
可选的。查阅要求的范围如第3.3节所述。

客户端必须使用授权服务器进行身份验证，如3.2.1节所述。
例如，客户端使用传输层安全性发出以下HTTP请求（带有额外的换行符仅用于显示目的）：

POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded

 grant_type=client_credentials

授权服务器必须对客户端进行身份验证。

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: grant_type REQUIRED. Value MUST be set to “client_credentials“. scope OPTIONAL. The scope of the access request as described by Section 3.3.

The client MUST authenticate with the authorization server as described in Section 3.2.1. For example, the client makes the following HTTP request using transport-layer security (with extra line breaks for display purposes only): 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.

4.4.3. 访问令牌响应（Access Token Response）

如果访问令牌请求有效且已授权，授权服务器将发出一个访问令牌，如章节5.1所述。不应该包含刷新令牌。如果请求客户端身份验证失败或无效，授权服务器将返回一个错误响应，如5.2节所述。

成功响应示例：

 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"
 }

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.

An example successful response: 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” }

4.5 其他扩展授权（Extension Grants）

客户端使用扩展授权类型，方法是使用绝对URI（由授权服务器定义）指定授权类型作为令牌端点的“ grant_type”参数的值，并添加任何必要的附加参数。

例如，要使用[OAuth-SAML2]定义的安全断言标记语言(SAML) 2.0断言授权类型请求访问令牌，客户端可以使用TLS发出以下HTTP请求(仅为显示目的使用额外的换行符):

 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-

如果访问令牌请求有效且已授权，授权服务器将发出访问令牌和可选刷新令牌，如章节5.1所述。如果请求客户端身份验证失败或无效，授权服务器将返回一个错误响应，如5.2节所述。

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.

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): 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-

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. 发放令牌（Issuing an Access Token）

如果访问令牌请求有效且已授权，授权服务器将发出访问令牌和可选刷新令牌，如章节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 成功响应（Successful Response）

授权服务器发出访问令牌和可选刷新令牌，并通过使用200 (OK)状态码向HTTP响应的实体体添加以下参数来构造响应:
access_token
必需的。授权服务器颁发的访问令牌。
token_type
必需的。令牌的类型如7.1节所述。值不区分大小写。
expires_in
推荐。访问令牌的生存期(以秒为单位)。例如，值“3600”表示访问令牌将在响应生成后一小时内到期。如果省略，授权服务器应通过其他方式提供过期时间或记录默认值。
refresh_token
可选的。刷新令牌，可以使用与第6节中描述的相同的授权授予来获取新的访问令牌。
scope
可选，如果与客户要求的范围相同;否则,必需的。访问令牌的范围，如章节3.3所述。

参数包含在HTTP响应的实体中，使用[RFC4627]定义的“application/json”媒体类型。通过在最高结构级别添加每个参数，这些参数被序列化到JavaScript对象表示法(JSON)结构中。参数名和字符串值作为JSON字符串包含。数值包含在JSON数字中。参数的顺序并不重要，而且可以变化。

授权服务器必须包含HTTP“Cache-Control”响应报头字段[RFC2616]，在任何包含令牌、凭据或其他敏感信息的响应中，值为“no-store”，以及值为“Pragma”响应报头字段[RFC2616]，值为“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"
 }

客户端必须忽略响应中无法识别的值名称。令牌的大小和从授权服务器接收的其他值保持未定义。客户应该避免对值的大小做出假设。授权服务器应该记录它发出的任何值的大小。

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: access_token REQUIRED. The access token issued by the authorization server. token_type REQUIRED. The type of the token issued as described in Section 7.1. Value is case insensitive. 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. 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. 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.

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.

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”.

For example: 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"
 }

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.

5.2 错误响应（Error Response）

授权服务器以HTTP 400（错误请求）状态码响应（除非另行指定），并在响应中包含以下参数：
error
必需的。来自以下内容的单个ASCII [USASCII]错误代码：
invalid_request
该请求缺少必需的参数，包括不受支持的参数值（授权类型除外），重复参数，包括多个凭据，使用多个身份验证客户端的机制或格式错误。
invalid_client
客户端身份验证失败（例如，未知客户端，不包括客户端身份验证或不支持的身份验证方法）。授权服务器可以返回HTTP 401（未授权）状态码，以指示支持哪些HTTP认证方案。如果客户端尝试通过“Authorization”请求头字段进行身份验证，则授权服务器务必使用HTTP 401（未授权）状态码进行响应，并包括与客户端使用的身份验证方案匹配的“ WWW-Authenticate”响应头字段。
invalid_grant
所提供的授权授权（例如，授权代码，资源所有者凭证）或刷新令牌无效，已过期，已吊销，与授权请求中使用的重定向URI不匹配或已发行给另一个客户端。
unauthorized_client
经认证的客户端无权使用此授权授予类型。
unsupported_grant_type
授权服务器不支持授权授予类型。
invalid_scope
请求的范围无效，未知，格式错误或超出了资源所有者授予的范围。
“error”参数的值不得包含设置为％x20-21 /％x23-5B /％x5D-7E之外的字符。
error_description
可选的。人类可读的ASCII [USASCII]文本，提供了其他信息，用于帮助客户端开发人员了解所发生的错误。 “ error_description”参数的值不得包含超出设置的％x20-21 /％x23-5B /％x5D-7E的字符。
error_uri
可选的。一个URI，用于标识人类可读的网页以及有关该错误的信息，用于向客户端开发人员提供有关该错误的其他信息。参数“ error_uri”的值必须符合URI引用语法，因此不得包含％x21 /％x23-5B /％x5D-7E集以外的字符。

参数包含在HTTP响应的实体中，使用[RFC4627]定义的“application/json”媒体类型。通过在最高结构级别添加每个参数，这些参数被序列化到JSON结构中。参数名和字符串值作为JSON字符串包含。数值包含在JSON数字中。参数的顺序并不重要，而且可以变化。

示例：

 HTTP/1.1 400 Bad Request
 Content-Type: application/json;charset=UTF-8
 Cache-Control: no-store
 Pragma: no-cache
 {
   "error":"invalid_request"
 }

The authorization server responds with an HTTP 400 (Bad Request) status code (unless specified otherwise) and includes the following parameters with the response: error REQUIRED. A single ASCII [USASCII] error code from the following: 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. 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. 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. unauthorized_client The authenticated client is not authorized to use this authorization grant type. 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. Values for the “error” parameter MUST NOT include characters outside the set %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. 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.

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.

For example: HTTP/1.1 400 Bad Request Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache

 {
   "error":"invalid_request"
 }

6. 刷新访问令牌（Refreshing an Access Token）

如果授权服务器向客户端发出刷新令牌，客户端向令牌端点发出刷新请求，使用附录B中的“application/x-www-form-urlencoded”格式，并在HTTP请求实体-body中使用UTF-8字符编码:
grant_type
必需的。值必须设置为“refresh_token”。
refresh_token
必需的。发送给客户端的刷新令牌。
scope
可选的。查阅要求的范围如第3.3节所述。所请求的范围必须不包括最初不是由资源所有者授予的任何范围，如果省略，则视为与最初由资源所有者授予的范围相等。

由于刷新令牌通常是用于请求其他访问令牌的持久凭据，刷新令牌被绑定到发出它的客户端。如果客户端类型是机密的，或者客户端获得了客户端凭证(或分配了其他身份验证要求)，客户端必须按照3.2.1节所述使用授权服务器进行身份验证。
例如，客户端使用传输层安全性发出以下HTTP请求（带有额外的换行符仅用于显示目的）：

 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

授权服务器必须：

• 要求对机密客户端或任何获得客户端凭据（或具有其他身份验证要求）的客户端进行客户端身份验证，
• 如果包括客户端身份验证，则对客户端进行身份验证，并确保将刷新令牌发布给已身份验证的客户端，并且
• 验证刷新令牌。

如果有效并获得授权，授权服务器将按照第5.1节中的说明发出访问令牌。 如果请求验证失败或无效，授权服务器将返回错误响应，如5.2节所述。
授权服务器可以发布一个新的刷新令牌，在这种情况下，客户端必须丢弃旧的刷新令牌，并用新的刷新令牌替换它。 在向客户端发出新的刷新令牌之后，授权服务器可以撤销旧的刷新令牌。 如果发布了新的刷新令牌，则刷新令牌范围必须与客户端在请求中包括的刷新令牌的范围相同。

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: grant_type REQUIRED. Value MUST be set to “refresh_token”. refresh_token REQUIRED. The refresh token issued to the client. 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.

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.

For example, the client makes the following HTTP request using transport-layer security (with extra line breaks for display purposes only): 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

The authorization server MUST:

• require client authentication for confidential clients or for any client that was issued client credentials (or with other authentication requirements),
• authenticate the client if client authentication is included and ensure that the refresh token was issued to the authenticated client, and
• validate the refresh token.

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. 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.

7. 访问受保护资源（Accessing Protected Resources）

客户端通过向资源服务器提供访问令牌来访问受保护的资源。资源服务器必须验证访问令牌，并确保它没有过期，并且其范围涵盖所请求的资源。资源服务器用于验证访问令牌(以及任何错误响应)的方法超出了本规范的范围，但通常涉及资源服务器和授权服务器之间的交互或协调。

客户端使用访问令牌与资源服务器进行身份验证的方法取决于授权服务器发出的访问令牌的类型。通常，它涉及到使用HTTP“Authorization”请求报头字段[RFC2617]与使用的访问令牌类型规范定义的认证方案一起使用，如[RFC6750]。

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].

7.1 访问令牌类型（ Access Token Types）

访问令牌类型为客户端提供成功利用访问令牌发出受保护资源请求所需的信息(以及特定类型的属性)。如果客户端不理解令牌类型，就不能使用访问令牌。

例如，[RFC6750]中定义的“ bearer”令牌类型可以通过在请求中简单地包含访问令牌字符串来使用：

 GET /resource/1 HTTP/1.1
 Host: example.com
 Authorization: Bearer mF_9.B5f-4.1JqM

而[OAuth-HTTP-MAC]中定义的“mac”令牌类型是通过发出一个消息认证码(mac)密钥和访问令牌来使用的，该访问令牌用于签署HTTP请求的某些组件:

 GET /resource/1 HTTP/1.1
 Host: example.com
 Authorization: MAC id="h480djs93hd8",
                    nonce="274312:dj83hs9s",
                    mac="kDZvddkndxvhGRXZhvuDjEWhGeE="

以上示例仅用于说明目的。 建议开发人员在使用前查阅[RFC6750]和[OAuth-HTTP-MAC]规范。

每个访问令牌类型定义都指定了发送给客户端的其他属性（如果有）以及“ access_token”响应参数。它还定义了HTTP身份验证方法，用于在发出受保护的资源请求时包括访问令牌。

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: 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: 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.

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.

7.2 错误响应（Error Response）

如果资源访问请求失败，资源服务器应该将错误通知客户端。虽然此类错误响应的细节超出了本规范的范围，但本文在第11.4节中建立了一个公共注册表，用于在OAuth令牌身份验证模式之间共享错误值。

主要为OAuth令牌身份验证设计的新身份验证方案应该定义一种向客户端提供错误状态码的机制，允许的错误值在该规范建立的错误注册表中注册。

这样的方案可以将有效错误码的集合限制为注册值的一个子集。如果使用命名参数返回错误代码，则参数名称应该是“error”。

其他能够用于OAuth令牌身份验证的方案，但主要不是为此目的设计的，可能会以相同的方式将错误值绑定到注册表。

新的身份验证方案也可以选择指定“error_description”和“error_uri”参数的使用，以与本规范中它们的用法相同的方式返回错误信息。

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.

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.

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”.

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.

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.

8. 可扩展性（Extensibility）

8.1 定义访问令牌类型（Defining Access Token Types ）

访问令牌类型可以通过以下两种方式之一定义：

• 在访问令牌类型注册表中注册（按照第 11.1 节中的过程），
• 或者使用唯一的绝对 URI 作为其名称。

使用 URI 名称的类型应该仅限于不普遍适用的特定于供应商的实现，并且特定于使用它们的资源服务器的实现细节。

所有其他类型都必须注册。 类型名称必须符合类型名称 ABNF。 如果类型定义包括一个新的 HTTP 认证方案，类型名称应该与 HTTP 认证方案名称相同（由 [RFC2617] 定义）。 标记类型“example”保留用于示例。

 type-name  = 1*name-char
       name-char  = "-" / "." / "_" / DIGIT / ALPHA

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.

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.

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. type-name = 1*name-char name-char = “-“ / “.” / “_” / DIGIT / ALPHA

8.2 定义新的端点参数（Defining New Endpoint Parameters ）

与授权端点或令牌端点一起使用的新请求或响应参数按照第 11.2 节中的过程在 OAuth 参数注册表中定义和注册。
参数名称必须符合 param-name ABNF，并且参数值语法必须是明确定义的（例如，使用 ABNF，或对现有参数语法的引用）。

 param-name  = 1*name-char
        name-char   = "-" / "." / "_" / DIGIT / ALPHA

未注册的供应商特定参数扩展通常不适用并且特定于使用它们的授权服务器的实现细节应该使用一个供应商特定前缀，该前缀不太可能与其他注册值冲突（例如，以 ‘ companyname_’开头）。

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.

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).

 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_’).

8.3 定义新的授权授予类型（Defining New Authorization Grant Types ）

可以通过为新的授权授予类型分配一个唯一的绝对URI来定义它，以与“ grant_type”参数一起使用。 如果扩展授权类型需要其他令牌端点参数，则必须按照第11.2节中的说明，在OAuth Parameters注册表中注册它们。

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.

8.4 定义新的授权端点响应类型（Defining New Authorization Endpoint Response Types）

与授权端点一起使用的新响应类型按照第 11.3 节中的过程在授权端点响应类型注册表中定义和注册。 响应类型名称必须符合响应类型 ABNF。

 response-type  = response-name *( SP response-name )
 response-name  = 1*response-char
 response-char  = "_" / DIGIT / ALPHA

如果响应类型包含一个或多个空格字符 (%x20)，则将其作为空格分隔的值列表进行比较，其中值的顺序无关紧要。 只能注册一个顺序的值，它涵盖了同一组值的所有其他排列。

比如，响应类型”token code”在本规范中并未定义，因此可以将其定义为扩展的响应类型，一旦注册，那与其顺序不同的”code token”就不能再注册为新的响应类型，但这两个顺序不同的值都可以同时用来表明同一种响应类型

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.

 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.

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.

8.5 定义其他错误代码（Defining Additional Error Codes）

当进行协议扩展时（访问令牌类型扩展、参数扩展以及授权类型扩展等），如果需要额外的错误码与授权码流程错误码、隐式授权模式错误码、令牌错误响应以及资源访问错误响应等配合使用，那这些额外的错误码需要进行定义。
如果扩展的错误码需要与已注册的令牌类型、已注册的端点参数或者一个扩展的授权类型一起使用，那该错误码必须进行注册（遵循章节11.4）。如果与未注册的扩展点配合使用，则可注册也可不注册。

错误代码必须符合错误 ABNF 并且应该在可能的情况下以识别名称作为前缀。 例如，识别设置为扩展参数“example”的无效值的错误应该被命名为“example_invalid”。

 error      = 1*error-char<br />     error-char = %x20-21 / %x23-5B / %x5D-7E

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.

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.

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”.

 error      = 1*error-char
 error-char = %x20-21 / %x23-5B / %x5D-7E

9. 本地应用（Native Applications）

本地应用是在资源所有者使用的设备上安装和执行的客户端(例如，桌面应用程序、本机移动应用程序)。本地应用需要特别考虑安全性、平台功能和总体终端用户体验。

授权端点要求客户端与资源所有者的用户代理之间进行交互。 本机应用程序可以调用外部用户代理，也可以在应用程序中嵌入用户代理。

示例：
外部用户代理-本地应用程序可以使用重定向URI捕获授权服务器的响应，该重定向URI已在操作系统中注册，可以调用客户端作为处理程序，手动复制和粘贴凭据，运行本地Web 服务器，安装用户代理扩展或通过提供重定向URI来标识在客户端控制下的服务器托管资源，从而使响应可用于本机应用程序。
嵌入式用户代理——本机应用程序通过监视资源加载过程发出的状态变化，或访问用户代理的cookie存储，直接与嵌入式用户代理通信，从而获得响应。

在外部或嵌入式用户代理之间进行选择时，开发人员应考虑以下事项：

• 外部用户代理可以提高完成率，因为资源所有者可能已经有与授权服务器的活动会话，从而无需重新身份验证。它提供熟悉的终端用户体验和功能。资源所有者还可以依赖用户代理功能或扩展来帮助进行身份验证(例如，密码管理器、双因素设备读取器)。
• 嵌入式用户代理可以提供更高的可用性，因为它无需切换上下文和打开新窗口。
• 嵌入式用户代理带来了安全挑战，因为资源所有者在一个未标识的窗口中进行身份验证，而无法访问大多数外部用户代理中的可视保护。嵌入式的user-agent引导终端用户信任身份验证的未识别请求(使得钓鱼攻击更容易执行)。
• 
  

在隐式授予类型和授权码授予类型之间进行选择时，应考虑以下因素：

• 由于本机应用程序无法对客户端凭据进行保密，因此使用授权码授予类型的本机应用程序应该不使用客户端凭据。
• 使用隐式授予类型流时，不返回刷新令牌，刷新令牌需要在访问令牌到期后重复授权过程。

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 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.

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 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 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).

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 When using the implicit grant type flow, a refresh token is not returned, which requires repeating the authorization process once the access token expires.

10. 安全注意事项（Security Considerations）

作为一个灵活且可扩展的框架，OAuth 的安全考虑取决于许多因素。 以下部分为实施者提供了安全指南，重点关注第 2.1 节中描述的三个客户端配置文件：Web 应用程序、基于用户代理的应用程序和本机应用程序。

[OAuth-THREATMODEL] 提供了全面的 OAuth 安全模型和分析，以及协议设计的背景。

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.

A comprehensive OAuth security model and analysis, as well as background for the protocol design, is provided by [OAuth-THREATMODEL].

10.1 客户端身份验证（Client Authentication ）

授权服务器与 Web 应用程序客户端建立客户端凭据以进行客户端身份验证。 鼓励授权服务器考虑比客户端密码更强的客户端身份验证方法。 Web 应用程序客户端必须确保客户端密码和其他客户端凭据的机密性。

授权服务器不可以为了客户认证的目的而向本地应用程序或基于用户代理的应用程序客户发出客户密码或其他客户凭证。 授权服务器可以为特定设备上的本地应用程序客户端的特定安装发布客户端密码或其他凭证。

当客户认证无法实现时，授权服务器应采用其他方式来验证客户的身份，例如，要求注册客户重定向URI或请资源所有者确认身份。 当要求资源所有者授权时，一个有效的重定向URI并不足以验证客户的身份，但可以用来防止在获得资源所有者授权后向假冒的客户提供凭证。

授权服务器必须考虑与未经身份验证的客户端交互的安全隐患，并采取措施限制向此类客户端颁发的其他凭据（例如刷新令牌）的潜在暴露。

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.

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.

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.

10.2 客户模拟（Client Impersonation ）

如果被模拟的客户端未能或无法将其客户端凭据保密，则恶意客户端可以模拟另一个客户端并获得对受保护资源的访问权限。

只要可能，授权服务器必须对客户端进行身份验证。如果授权服务器由于客户端的特性而不能对客户端进行身份验证，那么授权服务器必须要求注册用于接收授权响应的任何重定向URI，并且应该使用其他方法来保护资源所有者免受此类潜在恶意客户端的攻击。例如，授权服务器可以让资源所有者协助识别客户端及其来源。

授权服务器应该执行显式的资源所有者身份验证，并向资源所有者提供有关客户端和请求的授权范围和生命周期的信息。由资源所有者来检查当前客户机上下文中的信息，并授权或拒绝请求。

授权服务器不应该在没有验证客户端或依赖其他措施的情况下自动处理重复的授权请求（没有主动的资源所有者交互），以确保重复的请求来自原始客户端而不是模仿者。

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.

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.

10.3 访问令牌（Access Tokens ）

访问令牌凭据（以及任何机密的访问令牌属性）必须在传输和存储过程中保密，并且只能在授权服务器、访问令牌对其有效的资源服务器以及访问令牌颁发给的客户端之间共享 . 访问令牌凭证必须仅使用 TLS 传输，如第 1.6 节所述，并使用 [RFC2818] 定义的服务器身份验证。

使用隐式授权类型时，访问令牌在 URI 片段中传输，这可能会将其暴露给未授权方。

授权服务器必须确保未授权方无法生成、修改或猜测访问令牌以生成有效的访问令牌。

客户端应该以最小的范围请求访问令牌。授权服务器在选择如何接受请求的范围时应该考虑客户端的身份，并且可能会发出一个权限小于请求的访问令牌。

该规范没有为资源服务器提供任何方法，以确保由给定客户端提供给它的访问令牌被授权服务器颁发给该客户端。

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].

When using the implicit grant type, the access token is transmitted in the URI fragment, which can expose it to unauthorized parties.

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.

10.4 刷新令牌（Refresh Tokens ）

授权服务器可以向 Web 应用程序客户端和本机应用程序客户端发出刷新令牌。

刷新令牌在传输和存储过程中必须保密，并且只能在授权服务器和刷新令牌发给的客户端之间共享。 授权服务器必须维护刷新令牌和它被颁发给的客户端之间的绑定。 刷新令牌必须仅使用 TLS 传输，如第 1.6 节所述，并具有 [RFC2818] 定义的服务器身份验证。

每当可以验证客户端标识时，授权服务器必须验证刷新令牌和客户端标识之间的绑定。当客户端身份验证不可能时，授权服务器应该部署其他方法来检测刷新令牌滥用。

例如，授权服务器可以使用刷新令牌轮换，其中每个访问令牌刷新响应都会发出一个新的刷新令牌。 先前的刷新令牌已失效但由授权服务器保留。 如果刷新令牌被破坏并随后被攻击者和合法客户端使用，其中之一将提供无效的刷新令牌，这将通知授权服务器该漏洞。

授权服务器必须确保未授权方无法生成、修改或猜测刷新令牌以生成有效的刷新令牌。

Authorization servers MAY issue refresh tokens to web application clients and native application clients.

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].

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.

10.5 授权码（Authorization Codes ）

授权码的传输应该通过安全通道进行，如果 URI 标识网络资源，客户端应该要求使用带有重定向 URI 的 TLS。 由于授权代码是通过用户代理重定向传输的，因此它们可能会通过用户代理历史记录和 HTTP 引用标头被披露。

授权码作为明文承载凭证操作，用于验证在授权服务器上授予授权的资源所有者是返回到客户端完成流程的同一个资源所有者。 因此，如果客户端依靠授权码进行自己的资源所有者认证，那么客户端重定向端点必须要求使用TLS。

授权码必须是短暂的和一次性的。 如果授权服务器观察到多次试图用授权码交换访问令牌的行为，授权服务器应该尝试撤销所有已经根据被破坏的授权码授予的访问令牌。

如果客户端可以通过身份验证，授权服务器必须对客户端进行身份验证，并确保授权代码是发给同一个客户端的。

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.

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.

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.

10.6 授权码重定向URI操作（Authorization Code Redirection URI Manipulation）

当使用授权码授权类型请求授权时，客户端可以通过“redirect_uri”参数指定重定向 URI。 如果攻击者可以操纵重定向 URI 的值，则可以导致授权服务器将资源所有者用户代理重定向到攻击者使用授权码控制的 URI。

攻击者可以在合法客户端创建帐户并启动授权流程。 当攻击者的用户代理被发送到授权服务器以授予访问权限时，攻击者会抓取合法客户端提供的授权 URI，并将客户端的重定向 URI 替换为攻击者控制下的 URI。 然后，攻击者诱骗受害者访问被操纵的链接以授权访问合法客户端。

一旦到达授权服务器，受害者就会收到一个代表合法和可信客户端的正常、有效的请求，并授权该请求。 然后将受害者重定向到攻击者控制下的端点，并使用授权码。 攻击者使用客户端提供的原始重定向URI向客户端发送授权码，完成授权流程。 客户端与访问令牌交换授权代码并将其链接到攻击者的客户端帐户，现在可以访问受害者授权的受保护资源（通过客户端）。

为了防止此类攻击，授权服务器必须确保用于获取授权代码的重定向 URI 与将授权代码交换为访问令牌时提供的重定向 URI 相同。 授权服务器必须要求公共客户端并且应该要求机密客户端注册他们的重定向 URI。 如果请求中提供了重定向 URI，则授权服务器必须根据注册值对其进行验证。

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.

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 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.

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).

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.

10.7 资源所有者密码凭证（Resource Owner Password Credentials ）

资源所有者密码凭据授予类型通常用于遗留或迁移原因。 它降低了客户端存储用户名和密码的总体风险，但并没有消除向客户端公开高特权凭据的需要。

这种授权类型比其他授权类型具有更高的风险，因为它维护了该协议试图避免的密码反模式。 客户端可能会滥用密码，或者密码可能会无意中泄露给攻击者（例如，通过客户端保存的日志文件或其他记录）。

此外，由于资源所有者无法控制授权过程（资源所有者的参与在将其凭据移交给客户端时结束），因此客户端可以获得比资源所有者所需范围更广的访问令牌。 授权服务器应考虑通过此授权类型发布的访问令牌的范围和生命周期。

授权服务器和客户端应该尽量减少这种授权类型的使用，并尽可能使用其他授权类型。

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.

10.8 请求保密（Request Confidentiality）

访问令牌、刷新令牌、资源所有者密码和客户端凭证不得以明文形式传输。 授权代码不应以明文形式传输。

“state”和“scope”参数不应该以纯文本形式包含敏感的客户端或资源所有者信息，因为它们可以通过不安全的通道传输或不安全地存储。

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.

10.9 确保端点真实性（Ensuring Endpoint Authenticity）

为了防止中间人攻击，对于发送到授权和令牌端点的任何请求，授权服务器必须要求使用 TLS 和 [RFC2818] 定义的服务器身份验证。 客户端必须验证授权服务器的 TLS 证书，如[RFC6125]所定义并符合其对服务器身份认证的要求。

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.

10.10 凭证猜测攻击（Credentials-Guessing Attacks）

授权服务器必须防止攻击者猜测访问令牌、授权代码、刷新令牌、资源所有者密码和客户端凭据。

攻击者猜测生成的令牌（以及其他不打算由最终用户处理的凭据）的概率必须小于或等于 2^(-128) 并且应该小于或等于 2^(-160)。

授权服务器必须使用其他方法来保护供最终用户使用的凭据。

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).

The authorization server MUST utilize other means to protect credentials intended for end-user usage.

10.11 网络钓鱼攻击（Phishing Attacks ）

这种协议和类似协议的广泛部署可能会导致终端用户习惯于被重定向到要求他们输入密码的网站。如果终端用户在输入他们的凭证之前不小心验证这些网站的真实性，攻击者就有可能利用这种做法窃取资源所有者的密码。
服务提供者应努力教育最终用户关于网络钓鱼攻击的风险，并应提供机制，使最终用户更容易确认其网站的真实性。
客户端开发人员应该考虑他们如何与用户代理(例如，外部的，嵌入式的)交互的安全影响，以及最终用户验证授权服务器的真实性的能力。
为了降低网络钓鱼攻击的风险，授权服务器必须要求在用于最终用户交互的每个端点上使用 TLS。

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.

10.12 跨站请求伪造（Cross-Site Request Forgery ）

跨站点请求伪造(CSRF)是一种利用，攻击者使受害者终端用户的用户代理遵循一个恶意的URI(例如，作为误导用户代理的链接、图像或重定向提供给用户代理)到一个可信的服务器(通常通过有效的会话cookie建立)。

针对客户端重定向URI的CSRF攻击允许攻击者注入自己的授权代码或访问令牌，这可能导致客户端使用与攻击者的受保护资源相关联的访问令牌，而不是受害者的(例如，将受害者的银行帐户信息保存到攻击者控制的受保护资源中)。

客户端必须为其重定向URI实现CSRF保护。这通常是通过要求发送到重定向URI端点的任何请求包含一个值来实现的，该值将请求绑定到用户代理的已验证状态(例如，用于验证用户代理的会话cookie的哈希值)。当发出授权请求时，客户端应该利用“state”请求参数将这个值传递给授权服务器。

一旦从最终用户获得授权，授权服务器将最终用户的用户代理重定向回客户端，并使用“state”参数中包含的所需绑定值。 绑定值使客户端能够通过将绑定值与用户代理的身份验证状态进行匹配来验证请求的有效性。 用于 CSRF 保护的绑定值必须包含一个不可猜测的值（如第 10.10 节所述），并且用户代理的身份验证状态（例如，会话 cookie、HTML5 本地存储）必须保存在只能由客户端访问的位置 和用户代理（即受同源策略保护）。

针对授权服务器的授权端点的 CSRF 攻击可能导致攻击者在不涉及或警告最终用户的情况下获得恶意客户端的最终用户授权。

授权服务器必须为其授权端点实现 CSRF 保护，并确保恶意客户端在没有资源所有者的意识和明确同意的情况下无法获得授权。

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).

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).

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.

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).

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.

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.

10.13 点击劫持（Clickjacking ）

在点击劫持攻击中，攻击者注册一个合法的客户端，然后构建一个恶意站点，在一个透明的 iframe 中加载授权服务器的授权端点网页，该 iframe 覆盖在一组虚拟按钮之上，这些虚拟按钮经过精心构建以直接放置 在授权页面的重要按钮下。 当最终用户单击误导性的可见按钮时，最终用户实际上是在单击授权页面上的不可见按钮（例如“授权”按钮）。 这允许攻击者在最终用户不知情的情况下欺骗资源所有者授予其客户端访问权限。

为了防止这种形式的攻击，本机应用程序应该在请求最终用户授权时使用外部浏览器而不是在应用程序中嵌入浏览器。 对于大多数较新的浏览器，授权服务器可以使用（非标准）“x-frame-options”标头强制避免 iframe。 此标头可以有两个值，“deny”和“sameorigin”，它们将分别阻止任何框架或由具有不同来源的站点构成的框架。 对于较旧的浏览器，可以使用 JavaScript frame-busting 技术，但可能不适用于所有浏览器。

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.

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.

10.14 代码注入和输入验证（Code Injection and Input Validation ）

当应用程序使用输入或其他外部变量时未净化并导致对应用程序逻辑的修改，就会发生代码注入攻击。 这可能允许攻击者无法访问应用程序设备或其数据，导致拒绝服务或引入广泛的恶意副作用。
授权服务器和客户端必须清理（并在可能的情况下验证）收到的任何值——特别是“state”和“redirect_uri”参数的值。

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 t 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.

10.15 开放重定向器（Open Redirectors）

授权服务器、授权端点和客户端重定向端点可能配置不当并作为开放重定向器运行。 开放式重定向器是一个端点，它使用参数自动将用户代理重定向到参数值指定的位置，而无需任何验证。

开放式重定向器可用于网络钓鱼攻击，或被攻击者使用熟悉且受信任的目的地的 URI 权限组件来让最终用户访问恶意站点。 另外，如果授权服务器只允许客户端注册重定向URI的一部分，攻击者可以使用客户端操作的开放重定向器构造重定向URI，该重定向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 bythe 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.

10.16 滥用访问令牌来模拟资源（Misuse of Access Token to Impersonate Resource）

对于使用隐式流的公共客户端，本规范没有为客户端提供任何方法来确定访问令牌颁发给哪个客户端。

资源所有者可以通过向攻击者的恶意客户端授予访问令牌来自愿委托对资源的访问。 这可能是由于网络钓鱼或其他一些借口。 攻击者还可以通过某种其他机制窃取令牌。 然后，攻击者可能会尝试通过向合法公共客户端提供访问令牌来冒充资源所有者。

在隐式流（response_type=token）中，攻击者可以轻松地切换来自授权服务器的响应中的令牌，将真实的访问令牌替换为之前发给攻击者的令牌。

与依赖于在后端通道中传递访问令牌以识别客户端用户的本机应用程序通信的服务器可能会同样受到攻击者的攻击，该攻击者创建了一个可以注入任意窃取的访问令牌的受感染应用程序。

任何假设只有资源所有者才能向其提供资源的有效访问令牌的公共客户端都容易受到此类攻击。

这种类型的攻击可能会将合法客户端资源所有者的信息暴露给攻击者（恶意客户端）。 这也将允许攻击者使用与最初授予访问令牌或授权代码的资源所有者相同的权限在合法客户端上执行操作。

向客户端验证资源所有者超出了本规范的范围。 任何使用授权过程作为委托给客户端的最终用户身份验证形式的规范（例如，第三方登录服务）不得在没有额外安全机制的情况下使用隐式流程，这些安全机制将使客户端能够确定访问 令牌是为其使用而颁发的（例如，受众限制访问令牌）。

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.

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).

11. IANA的注意事项（ IANA Considerations）

11.1 OAuth访问令牌类型注册表（OAuth Access Token Types Registry）

本规范建立OAuth访问令牌类型注册表。

在oauth-ext-review@ietf.org邮件列表上的两周的审查期后，根据一位或多位指定的专家的建议下，按规范需求（RFC5226）注册访问令牌类型。然而，为允许发表之前的值的分配，指定的专家（们）一旦他们对这样的规范即将发布感到满意可以同意注册。

注册请求必须使用正确的主题（例如“访问令牌类型example”的请求）发送到oauth-ext-review@ietf.org邮件列表来审查和评论。

在审查期间，指定的专家（们）将同意或拒绝该注册请求，向审查列表和IANA通报该决定。拒绝应该包含解释，并且可能的话，包含如何使请求成功的建议。

IANA必须只接受来自指定的专家（们）的注册表更新并且应该引导所有注册请求至审查邮件列表。

This specification establishes the OAuth Access Token Types registry.

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.

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”).

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 must only accept registry updates from the Designated Expert(s) and should direct all requests for registration to the review mailing list.

11.1.1. Registration Template

• Type name：请求的名称（例如，“example”）。
• Additional Token Endpoint Response Parameters:随“access_token”参数一起返回的其他响应参数。 新的参数都必须如11.2节所述在OAuth参数注册表中分别注册。
• HTTP Authentication Scheme(s):HTTP身份验证方案名称，如果有的话，用于使用这种类型的访问令牌对受保护资源进行身份验证。
• Change controller：对于标准化过程的RFC，指定为“IETF”。 对于其他，给出负责的部分的名称。 其他细节（例如，邮政地址，电子邮件地址，主页URI）也可以包括在内。
• Specification document(s):指定参数的文档的引用文献，最好包括可以用于检索文档副本的URI。 相关章节的指示也可以包含但不是必需的。

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.

HTTP Authentication Scheme(s): The HTTP authentication scheme name(s), if any, used to authenticate protected resource requests using access tokens of this type.

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. 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.

11.2 OAuth参数注册表（OAuth Parameters Registry）

本规范建立OAuth参数注册表。

在oauth-ext-review@ietf.org邮件列表上的两周的审查期后，根据一位或多位指定的专家的建议下，按规范需求（RFC5226）注册列入授权端点请求、授权端点响应、令牌端点请求或令牌端点响应的其他参数。然而，为允许发表之前的值的分配，指定的专家（们）一旦他们对这样的规范即将发布感到满意可以同意注册。

注册请求必须使用正确的主题（例如，参数“example”的请求）发送到oauth-ext-review@ietf.org邮件列表来审查和评论。

在审查期间，指定的专家（们）将同意或拒绝该注册请求，向审查列表和IANA通报该决定。拒绝应该包含解释，并且可能的话，包含如何使请求成功的建议。

IANA必须只接受来自指定的专家（们）的注册表更新并且应该引导所有注册请求至审查邮件列表。

This specification establishes the OAuth Parameters registry.

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.

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”).

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 must only accept registry updates from the Designated Expert(s) and should direct all requests for registration to the review mailing list.

11.2.1. 注册模板（Registration Template）

• Parameter name:请求的名称（例如，“example”）。
• Parameter usage location:参数可以使用的位置。 可能的位置为授权请求、授权响应、令牌请求或令牌响应。
• Change controller:对于标准化过程的RFC，指定为“IETF”。对于其他，给出负责的部分的名称。其他细节（例如，邮政地址，电子邮件地址，主页URI）也可以包括在内。
• Specification document(s):指定参数的文档的引用文献，最好包括可以用于检索文档副本的URI。相关章节的指示也可以包含但不是必需的。

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. 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.

11.2.2. 初始注册内容（Initial Registry Contents）

OAuth参数注册表中的初始内容：

• Parameter name: client_id
• Parameter usage location: authorization request, token request
• Change controller: IETF
• Specification document(s): RFC 6749
• Parameter name: client_secret
• Parameter usage location: token request
• Change controller: IETF
• Specification document(s): RFC 6749
• Parameter name: response_type
• Parameter usage location: authorization request
• Change controller: IETF
• Specification document(s): RFC 6749
• Parameter name: redirect_uri
• Parameter usage location: authorization request, token request
• Change controller: IETF
• Specification document(s): RFC 6749
• Parameter name: scope
• Parameter usage location: authorization request, authorization response, token request, token response
• Change controller: IETF
• Specification document(s): RFC 6749
• Parameter name: state
• Parameter usage location: authorization request, authorization response
• Change controller: IETF
• Specification document(s): RFC 6749
• Parameter name: code
• Parameter usage location: authorization response, token request
• Change controller: IETF
• Specification document(s): RFC 6749
• Parameter name: error_description
• Parameter usage location: authorization response, token response
• Change controller: IETF
• Specification document(s): RFC 6749
• Parameter name: error_uri
• Parameter usage location: authorization response, token response
• Change controller: IETF
• Specification document(s): RFC 6749
• Parameter name: grant_type
• Parameter usage location: token request
• Change controller: IETF
• Specification document(s): RFC 6749
• Parameter name: access_token
• Parameter usage location: authorization response, token response
• Change controller: IETF
• Specification document(s): RFC 6749
• Parameter name: token_type
• Parameter usage location: authorization response, token response
• Change controller: IETF
• Specification document(s): RFC 6749
• Parameter name: expires_in
• Parameter usage location: authorization response, token response
• Change controller: IETF
• Specification document(s): RFC 6749
• Parameter name: username
• Parameter usage location: token request
• Change controller: IETF
• Specification document(s): RFC 6749
• Parameter name: password
• Parameter usage location: token request
• Change controller: IETF
• Specification document(s): RFC 6749
• Parameter name: refresh_token
• Parameter usage location: token request, token response
• Change controller: IETF
• Specification document(s): RFC 6749

The OAuth Parameters registry’s initial contents are:

o Parameter name: client_id o Parameter usage location: authorization request, token request o Change controller: IETF o Specification document(s): RFC 6749

o Parameter name: client_secret o Parameter usage location: token request o Change controller: IETF o Specification document(s): RFC 6749

o Parameter name: response_type o Parameter usage location: authorization request o Change controller: IETF o Specification document(s): 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 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 Parameter name: state o Parameter usage location: authorization request, authorization response o Change controller: IETF o Specification document(s): 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 Parameter name: error_description o Parameter usage location: authorization response, token response o Change controller: IETF o Specification document(s): 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 Parameter name: grant_type o Parameter usage location: token request o Change controller: IETF o Specification document(s): 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 Parameter name: token_type o Parameter usage location: authorization response, token response o Change controller: IETF o Specification document(s): 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 Parameter name: username o Parameter usage location: token request o Change controller: IETF o Specification document(s): RFC 6749

o Parameter name: password o Parameter usage location: token request o Change controller: IETF o Specification document(s): 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

11.3 OAuth授权端点响应类型注册表（OAuth Authorization Endpoint Response Types Registry）

本规范建立OAuth授权端点响应类型注册表。

在oauth-ext-review@ietf.org邮件列表上的两周的审查期后，根据一位或多位指定的专家的建议下，按规范需求（RFC5226）注册授权端点使用的其他响应类型。然而，为允许发表之前的值的分配，指定的专家（们）一旦他们对这样的规范即将发布感到满意可以同意注册。

注册请求必须使用正确的主题（例如“响应类型example”的请求）发送到oauth-ext-review@ietf.org邮件列表来审查和评论。

在审查期间，指定的专家（们）将同意或拒绝该注册请求，向审查列表和IANA通报该决定。

IANA必须只接受来自指定的专家（们）的注册表更新并且应该引导所有注册请求至审查邮件列表。

This specification establishes the OAuth Authorization Endpoint Response Types registry.

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.

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”).

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 must only accept registry updates from the Designated Expert(s) and should direct all requests for registration to the review mailing list.

11.3.1. 注册模板（Registration Template）

• Response type name:请求的名称（例如，“example”）。
• Change controller:对于标准化过程的RFC，指定为“IETF”。对于其他，给出负责的部分的名称。其他细节（例如，邮政地址，电子邮件地址，主页URI）也可以包括在内。
• Specification document(s):指定参数的文档的引用文献，最好包括可以用于检索文档副本的URI。相关章节的指示也可以包含但不是必需的

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.

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.

11.3.2. 初始注册内容（Initial Registry Contents）

OAuth授权端点响应类型注册表的初始内容：

• Response type name: code
• Change controller: IETF
• Specification document(s): RFC 6749
• Response type name: token
• Change controller: IETF
• Specification document(s): RFC 6749

The OAuth Authorization Endpoint Response Types registry’s initial contents are:

o Response type name: code o Change controller: IETF o Specification document(s): RFC 6749

o Response type name: token o Change controller: IETF o Specification document(s): RFC 6749

11.4 OAuth扩展错误注册表（ OAuth Extensions Error Registry ）

本规范建立OAuth扩展错误注册表。

在oauth-ext-review@ietf.org邮件列表上的两周的审查期后，根据一位或多位指定的专家的建议下，按规范需求（RFC5226）注册与其他协议扩展（例如，扩展的许可类型、访问令牌类型或者扩展参数）一起使用的其他错误代码。然而，为允许发表之前的值的分配，指定的专家（们）一旦他们对这样的规范即将发布感到满意可以同意注册。

注册请求必须使用正确的主题（例如“错误代码example”的请求）发送到oauth-ext-review@ietf.org邮件列表来审查和评论。

在审查期间，指定的专家（们）将同意或拒绝该注册请求，向审查列表和IANA通报该决定。拒绝应该包含解释，并且可能的话，包含如何使请求成功的建议。

IANA必须只接受来自指定的专家（们）的注册表更新并且应该引导所有注册请求至审查邮件列表。

This specification establishes the OAuth Extensions Error registry.

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.

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”).

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 must only accept registry updates from the Designated Expert(s) and should direct all requests for registration to the review mailing list.

11.4.1. 注册模板（Registration Template）

• Error name:请求的名称（例如，“example”）。错误名称的值
  不能包含集合%x20-21 /%x23-5B /%x5D-7E以外的字符。
• Error usage location:错误使用的位置。可能的位置是授权代码许可错误响应（4.1.2.1节），隐式许可错误响应（4.2.2.1节），令牌错误响应（5.2节），或资源访问错误的响应（7.2节）。
• Related protocol extension:与错语代码一起使用的扩展许可类型、访问令牌类型或扩展参数的名称。
• Change controller:对于标准化过程的RFC，指定为“IETF”。对于其他，给出负责的部分的名称。其他细节（例如，邮政地址，电子邮件地址，主页URI）也可以包括在内。
• Specification document(s):指定参数的文档的引用文献，最好包括可以用于检索文档副本的URI。相关章节的指示也可以包含但不是必需的。

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.

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).

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.

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.

12. 参考文献（References）

12.1 规范性文献（Normative References）

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate
Requirement Levels”, BCP 14, RFC 2119, March 1997.

[RFC2246] Dierks, T. and C. Allen, “The TLS Protocol Version 1.0”,
RFC 2246, January 1999.

[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.

[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.
[RFC2818] Rescorla, E., “HTTP Over TLS”, RFC 2818, May 2000.

[RFC3629] Yergeau, F., “UTF-8, a transformation format of
ISO 10646”, STD 63, RFC 3629, November 2003.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform
Resource Identifier (URI): Generic Syntax”, STD 66,
RFC 3986, January 2005.

[RFC4627] Crockford, D., “The application/json Media Type for
JavaScript Object Notation (JSON)”, RFC 4627, July 2006.

[RFC4949] Shirey, R., “Internet Security Glossary, Version 2”,
RFC 4949, August 2007.

[RFC5226] Narten, T. and H. Alvestrand, “Guidelines for Writing an
IANA Considerations Section in RFCs”, BCP 26, RFC 5226,
May 2008.

[RFC5234] Crocker, D. and P. Overell, “Augmented BNF for Syntax
Specifications: ABNF”, STD 68, RFC 5234, January 2008.

[RFC5246] Dierks, T. and E. Rescorla, “The Transport Layer Security
(TLS) Protocol Version 1.2”, RFC 5246, August 2008.

[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.

[USASCII] American National Standards Institute, “Coded Character
Set — 7-bit American Standard Code for Information
Interchange”, ANSI X3.4, 1986.

[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](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](http://www.w3.org/TR/2008/REC-xml-20081126).

12.1 参考性文献（Informative References）

[OAuth-HTTP-MAC]
Hammer-Lahav, E., Ed., “HTTP Authentication: MAC Access
Authentication”, Work in Progress, February 2012.

[OAuth-SAML2]
Campbell, B. and C. Mortimore, “SAML 2.0 Bearer Assertion
Profiles for OAuth 2.0”, Work in Progress, September 2012.

[OAuth-THREATMODEL]
Lodderstedt, T., Ed., McGloin, M., and P. Hunt, “OAuth 2.0
Threat Model and Security Considerations”, Work
in Progress, October 2012.

[OAuth-WRAP]
Hardt, D., Ed., Tom, A., Eaton, B., and Y. Goland, “OAuth
Web Resource Authorization Profiles”, Work in Progress,
January 2010.

[RFC5849] Hammer-Lahav, E., “The OAuth 1.0 Protocol”, RFC 5849,
April 2010.

[RFC6750] Jones, M. and D. Hardt, “The OAuth 2.0 Authorization
Framework: Bearer Token Usage”, RFC 6750, October 2012.

附录A.增强Backus-Naur格式（ABNF）语法（Appendix A. Augmented Backus-Naur Form (ABNF) Syntax）

本节提供了本文档中定义的元素按RFC5234记法的增强巴克斯诺尔范式（ABNF）的语法描述。下列ABNF用Unicode代码要点[W3C.REC-XML-20081126]的术语定义；这些字符通常以UTF-8编码。元素按首次定义的顺序排列。
一些定义遵循使用来自RFC3986“URI引用”的定义。
一些定义遵循使用这些通用的定义：

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

（UNICODECHARNOCRLF定义基于[W3C.REC-XML-20081126]2.2节中定义的字符，但忽略了回车和换行字符。）

• A.1. “client_id”语法
• A.2. “client_secret”语法
• A.3. “response_type”语法
• A.4. “scope”语法
• A.5. “state”语法
• A.6. “redirect_uri”语法
• A.7. “error”语法
• A.8. “error_description”语法
• A.9. “error_uri”语法
• A.10. “grant_type”语法
• A.11. “code”语法
• A.12. “access_token”语法
• A.13. “token_type”语法
• A.14. “expires_in”语法
• A.15. “username”语法
• A.16. “password”语法
• A.17. “refresh_token”语法
• A.18. 端点参数语法

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.

Some of the definitions that follow use the “URI-reference” definition from [RFC3986].

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

(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.)

A.1. “client_id” Syntax

The “client_id” element is defined in Section 2.3.1: client-id = *VSCHAR

A.2. “client_secret” Syntax

The “client_secret” element is defined in Section 2.3.1: client-secret = *VSCHAR

A.3. “response_type” Syntax

The “responsetype” element is defined in Sections 3.1.1 and 8.4: response-type = response-name ( SP response-name ) response-name = 1response-char response-char = ““ / DIGIT / ALPHA

A.4. “scope” Syntax

The “scope” element is defined in Section 3.3: scope = scope-token ( SP scope-token ) scope-token = 1NQCHAR

A.5. “state” Syntax

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: state = 1*VSCHAR

A.6. “redirect_uri” Syntax

The “redirect_uri” element is defined in Sections 4.1.1, 4.1.3, and 4.2.1: redirect-uri = URI-reference

A.7. “error” Syntax

The “error” element is defined in Sections 4.1.2.1, 4.2.2.1, 5.2, 7.2, and 8.5: error = 1*NQSCHAR

A.8. “error_description” Syntax

The “error_description” element is defined in Sections 4.1.2.1, 4.2.2.1, 5.2, and 7.2: error-description = 1*NQSCHAR

A.9. “error_uri” Syntax

The “error_uri” element is defined in Sections 4.1.2.1, 4.2.2.1, 5.2, and 7.2: error-uri = URI-reference

A.10. “grant_type” Syntax

The “granttype” element is defined in Sections 4.1.3, 4.3.2, 4.4.2, 4.5, and 6: grant-type = grant-name / URI-reference grant-name = 1*name-char name-char = “-“ / “.” / ““ / DIGIT / ALPHA

A.11. “code” Syntax

The “code” element is defined in Section 4.1.3: code = 1*VSCHAR

A.12. “access_token” Syntax

The “access_token” element is defined in Sections 4.2.2 and 5.1: access-token = 1*VSCHAR

A.13. “token_type” Syntax

The “tokentype” element is defined in Sections 4.2.2, 5.1, and 8.1: token-type = type-name / URI-reference type-name = 1*name-char name-char = “-“ / “.” / ““ / DIGIT / ALPHA

A.14. “expires_in” Syntax

The “expires_in” element is defined in Sections 4.2.2 and 5.1: expires-in = 1*DIGIT

A.15. “username” Syntax

The “username” element is defined in Section 4.3.2: username = *UNICODECHARNOCRLF

A.16. “password” Syntax

The “password” element is defined in Section 4.3.2: password = *UNICODECHARNOCRLF

A.17. “refresh_token” Syntax

The “refresh_token” element is defined in Sections 5.1 and 6: refresh-token = 1*VSCHAR

A.18. Endpoint Parameter Syntax

The syntax for new endpoint parameters is defined in Section 8.2: param-name = 1*name-char name-char = “-“ / “.” / “_” / DIGIT / ALPHA

附录B. application / x-www-form-urlencoded媒体类型的使用（Appendix B. Use of application/x-www-form-urlencoded Media Type）

在本规范公布的时候，“application/x-www-form-urlencoded”媒体类型在[W3C.REC-html401-19991224]的17.13.4节中定义但未在IANA MIME媒体类型注册表（[http://www.iana.org/assignments/media-types](http://www.iana.org/assignments/media-types)）中注册。此外，该定义是不完整的，因为它未考虑非US-ASCII的字符。

在使用这种媒体类型生成有效载荷使时为解决这个缺点，名称和值必须首先使用UTF-8字符编码方案RFC3629编码；作为结果的八位序列然后需要使用在[W3C.REC-html401-19991224]中定义的转义规则进一步编码。

当从使用这种媒体类型的有效载荷中解析数据时，由逆向名称/值编码得到的名称和值因而需要被视作八位序列，使用UTF-8字符编码方案解码。
例如，包含六个Unicode代码点的值

(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

将被编码成如下的八位序列（使用十六进制表示）：

20 25 26 2B C2 A3 E2 82 AC

然后在有效载荷中表示为：

+%25%26%2B%C2%A3%E2%82%AC

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](http://www.iana.org/assignments/media-types)). Furthermore, that definition is incomplete, as it does not consider non-US-ASCII characters.

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].

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.

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):

 20 25 26 2B C2 A3 E2 82 AC

and then represented in the payload as:

 +%25%26%2B%C2%A3%E2%82%AC

附录C.致谢（Appendix C. Acknowledgements）

最初的OAuth 2.0协议规范是由David Recordon编辑的，基于先前的两个发行版：OAuth 1.0社区规范RFC5849和OAuth WRAP（OAuth Web资源授权配置）[OAuth WRAP]。Eram Hammer然后编辑了包含在此RFC中的中间草稿。Torsten Lodderstedt, Mark McGloin, Phil Hunt, Anthony Nadalin和John Bradley起草了“安全注意事项”一节。使用“application/x-www-form.urlencoded”媒体类型一节由Julian Reschke起草。ABNF一节由Julian Reschke起草。

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, Todd Sieling, Brian Slesinsky以及Andy Smith撰写。
OAuth WRAP规范由 Dick Hardt编辑，由Brian Eaton, Yaron Y. Goland, Dick Hardt, and Allen Tom撰写。

本规范是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和Skylar Woodward.

本文档由主席团Blaine Cook, Peter Saint-Andre, Hannes Tschofenig, Barry Leiba和Derek Atkins出品。
区域指导包括 Lisa Dusseault, Peter Saint-Andre和Stephen Farrell.
作者署名

Dick Hardt (editor)
Microsoft

EMail: dick.hardt@gmail.com
URI: http://dickhardt.org/

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.

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.

The OAuth WRAP specification was edited by Dick Hardt and authored by Brian Eaton, Yaron Y. Goland, Dick Hardt, and 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:

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. 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.

Author’s Address

Dick Hardt (editor) Microsoft

EMail: dick.hardt@gmail.com URI: http://dickhardt.org/