1. 簡介 - Introduction
在傳統的客戶端-服務端認證模式中，客戶端需要使用資源所有者（如：最終用戶）的憑證（如：用戶名密碼）與服務端進行認證，以請求服務端上的訪問受限的資源（受保護資源）。為了向第三方應用提供對受限資源的訪問權限，資源所有者需要將自己的憑證共享給第三方。這就產生了幾個問題和局限：
- 為保證長期可用，第三方應用必須保存資源所有者的憑證，比如明文密碼。
- 服務端需要支持密碼驗證，盡管該方式存在固有的安全風險。
- 第三方應用對資源所有者的受保護資源的訪問權限過于寬泛，使得資源所有者沒有能力限制其訪問期限，或者限制其訪問受限資源的子集。
- 資源所有者在撤銷對某個第三方應用的訪問權限時，也勢必會撤銷對所有第三方應用的訪問權限，因為只能采取修改密碼的方式來實現撤銷。
- 任何第三方應用程序的泄露問題，都會導致最終用戶的密碼以及所有受改密碼保護的數據的泄露。
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通過提供授權層，以及將客戶端和資源所有者的角色分開的方式來解決這些問題。在OAuth中，客戶端請求訪問的資源，由資源所有者控制并由資源服務器托管，并且會獲得一套與資源所有者不同的憑證。
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.
為替代使用資源所有者憑證來訪問受保護資源的方式，客戶端改為獲取一個access token -- 一個標識特定范圍、壽命和其它訪問屬性的字符串。訪問令牌由授權服務器經資源所有者批準后簽發給第三方客戶端，客戶端通過攜帶access token來訪問被資源服務器托管的受保護資源。
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).
本規范是為HTTP設計的([RFC2616])，在HTTP以外的任何協議上使用OAuth都不在本規范的約定范圍內。
This specification is designed for use with HTTP ([RFC2616]). The
use of OAuth over any protocol other than HTTP is out of scope.
OAuth 1.0([RFC5849])協議，是一個小規模的臨時社區的成果，最終以資料的形式發布。本標準跟蹤（一份RFC規范說明想要提升到正式標準的程度，需要通過“成熟度等級”來評估，該過程稱為Standards Track）規范建立在OAuth 1.0部署經驗的基礎上，同時也從更廣泛的IETF社區搜集到額外的用例和可擴展性需求。OAuth 2.0協議不會向后兼容OAuth 1.0，這兩種版本的協議可以在網上共存，也都提供支持。然而，本文檔的目的是讓新的實現按照本文檔的規范來支持OAuth 2.0，0Auth 1.0僅用于支持現有的部署。OAuth 2.0與OAuth 1.0協議之間能共享的實踐細節很少，所以熟悉OAuth 1.0的實施人員不應該按OAuth 1.0的情況來假設本文檔的結構和細節。
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定義四種角色：
資源所有者
能夠授權訪問受保護資源的實體，如果資源所有者是個人，則稱為最終用戶。
資源服務器
托管受保護資源的服務器，能夠接收并響應攜帶access token訪問受保護資源的請求。
客戶端
作為資源所有者的“代理”，在其授權下訪問受保護資源的應用程序。其中“client（即客戶端）”一詞并不意味著任何特定的實施特征（如，該應用是在服務器、桌面或其它設備上運行）。
授權服務器
在成功認證資源所有者并獲得授權后，向客戶端簽發access token的服務器。
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
+--------+ +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+
圖一所示的OAuth 2.0的抽象流程描述了四個角色之間的交互，包括以下步驟：
- (A) 客戶端向資源所有者請求授予權限。授權請求可以由客戶端直接向資源所有者發起（如圖所示），或者更好的方式是由授權服務器作為中間人間接發起。
- (B) 客戶端接收到的授權許可，是代表資源所有者的授權憑證（如：Authorization Code），通常采用本規范中定義的四種授權類型或其它擴展類型來獲取。
- (C) 客戶端通過與授權服務器發起身份認證以及出式授權許可，來換取access token。
- (D) 授權服務器對客戶端進行身份認證，并驗證授權許可，如果驗證通過，則簽發access token。
- (E) 客戶端從資源服務器中請求訪問受保護的資源，并通過出示access token來獲取認證。
- (F) 資源服務器校驗access token，如果驗證通過，則處理該請求。
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.
客戶端從資源所有者處獲取授權許可的更好的方式（如步驟A和B中的描述），是使用授權服務器作為中間人，這會在4.1章節的圖3中說明。
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
授權許可是資源所有者授權的憑證（授權訪問其受保護的資源）。本規范定義了四種授權類型：
- authorization code
- implicit
- resource owner password credentials
- client credentials
以及定義其它類型的可擴展的機制。
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]中定義的user-agent），而授權服務器又在生成授權碼后，引導資源所有者回到客戶端。
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.
授權碼提供了一些重要的安全優勢，比如能夠對客戶端進行認證，同時可以直接將access token傳輸給客戶端，無需通過用戶的代理，也無需暴露給其他人，包括資源所有者自己。
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）實現的客戶端提供的。在隱式授權模式中，客戶端不會獲取到授權碼，而是直接獲取access token（作為資源所有者授權的結果）。該授權類型之所以稱為隱式授權模式，是因為沒有簽發中間憑證（如用于獲取access token的授權碼）。
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).
在隱式授權模式中簽發access token時，授權服務器不會對客戶端進行認證。在某些情況下，客戶端的身份可以通過將access token下發給客戶端的重定向URI來驗證（譯者注：比較不嚴謹的驗證方式）。訪問零盤可能會暴露給資源所有者，或其它可以訪問資源所有者代理的應用程序。
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.
隱式授權模式提高了某些客戶端的響應能力和效率（如構建在瀏覽器上的客戶端），因為它減少了獲取access token所需的通訊往返次數。然而，這種便利性與使用隱式授權模式帶來的安全問題需要進行權衡，例如10.3和10.16章節中描述的，特別是當授權碼模式可用時。
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).
盡管這種授權模式要求客戶端直接訪問資源所有者的憑證，但資源所有者的憑證僅用于單次請求換取access token。該授權模式可以使客戶端無需因將來的使用而存儲資源所有者憑證，而是用長效的access token或refresh token來交換令牌。
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
訪問令牌是用于訪問受保護資源的憑證，訪問令牌是一個代表資源所有者向客戶端簽發的憑證的字符串，該字符串對客戶端來說通常是不透明的。令牌代表由資源所有者授予的對資源的特定訪問范圍和時限，并由資源服務器和授權服務器配合強制執行這些控制。
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.
根據資源服務器的安全需求，訪問令牌可以有不同的格式、結構和使用方法（如加密屬性）。訪問令牌的屬性和用于訪問受保護資源的方法不再本規范的討論范圍內，而是由[RFC6750]等配套規范定義。
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）。
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.
+--------+ +---------------+
| |--(A)------- Authorization Grant --------->| |
| | | |
| |<-(B)----------- Access Token -------------| |
| | & Refresh Token | |
| | | |
| | +----------+ | |
| |--(C)---- Access Token ---->| | | |
| | | | | |
| |<-(D)- Protected Resource --| Resource | | Authorization |
| Client | | Server | | Server |
| |--(E)---- Access Token ---->| | | |
| | | | | |
| |<-(F)- Invalid Token Error -| | | |
| | +----------+ | |
| | | |
| |--(G)----------- Refresh Token ----------->| |
| | | |
| |<-(H)----------- Access Token -------------| |
+--------+ & Optional Refresh Token +---------------+
圖2所示的流程包括以下步驟：
- (A) 客戶端通過授權服務器進行身份驗證，并提出授權許可，申請訪問令牌。
- (B) 授權服務器對客戶端和授權許可進行驗證，如果有效，則簽發訪問令牌和刷新令牌。
- (C) 客戶端通過向資源服務器出示訪問令牌來訪問受保護的資源。
- (D) 資源服務器驗證訪問令牌，如果有效，則處理該請求。
- (E) 重復步驟C和D，直到訪問令牌過期，如果客戶端知道訪問令牌過期，則跳到步驟G，肉則，它就會發出另一個對受保護資源的訪問請求。
- (F) 由于訪問令牌無效，資源服務器返回令牌無效的錯誤。
- (G) 客戶端通過授權服務器進行身份驗證并出示刷新令牌來獲取新的訪問令牌。對客戶端認證的要求是基于客戶端類型和授權服務器的策略。
- (H) 授權服務器對客戶端進行認證，并驗證刷新令牌，如果有效，則下發新的訪問令牌（以及可選的新的刷新令牌）。
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 validates
the refresh token, and if valid, issues a new access token (and,
optionally, a new refresh token).
如第7章節所述，步驟C、D、E和F不屬于本規范的討論范圍。
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 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提供了一個具有良好安全屬性定義的豐富的授權框架，然而，作為一個具有許多可選組件的豐富的、高度可擴展的框架，該規范本身可能產生廣泛的不可互操作的實現。
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.
在設計該框架時，我們明確期望未來的工作將定義必要的規范性配置文件和擴展機制，以完整的實現web-scale。
This framework was designed with the clear expectation that future
work will define prescriptive profiles and extensions necessary to
achieve full web-scale interoperability.
2. 客戶端注冊 - Client Registration
在使用本協議之前，客戶端需要向授權服務器注冊。客戶端在授權服務器注冊的方式超過了本協議的討論范圍，但是通常是采用最終用戶與HTML注冊表單交互的方式。
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.
客戶端注冊的實現不需要客戶端與授權服務器進行直接交互。當授權服務器支持時，注冊可以通過其他方式來建立信任并獲取所需的客戶端屬性（如重定向URI、客戶端類型等）。比如，注冊可以通過自簽名或第三方簽發的斷言實現，或者授權服務器可以通過可信任的信道來進行客戶端發現。
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.
當注冊為一個客戶端時，客戶端的開發人員應該：
- 如2.1章節所述，聲明客戶端類型，
- 如3.1.2章節所述，提供客戶端的重定向URI，并且
- 攜帶授權服務器所需的其它信息（如：應用名、網站、描述、logo以及法律條款等）
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定義了兩種客戶端類型：
私密客戶端
能夠保障其憑證的保密性的客戶端（如在安全的服務器上部署的客戶端，對其憑證的訪問受到限制），或者有辦法通過別的方式進行安全認證的客戶端。
公開客戶端
客戶端無法保障其憑證的保密性（如客戶端運行在資源所有者的設備上，比如是本地應用或基于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.
客戶端可能作為分布式組件的方式部署，每個組件可能具有不同的客戶端類型和安全策略（比如，分布式客戶端可能同時具備私密的server-based組件以及公開的browser-based組件）。如果授權服務器對這類客戶端不提供支持，或者沒有沒有提供對其注冊方式的知道，那么客戶端應該對每個組件進行單獨的注冊。
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.
本規范圍繞以下的客戶端特征進行設計：
web application
web應用程序是運行在web服務器上的私密客戶端。資源所有者通過在自己設備上的用戶代理渲染的HTML來訪問客戶端的用戶界面。客戶端憑證或者任何訪問令牌都是存儲在web服務器上，不會暴露給資源所有者。
user-agent-based application
基于用戶代理的應用程序是公開客戶端，客戶端代碼從web服務器下載，并在資源所有者的設備的用戶代理（如web瀏覽器）中執行，協議的數據和客戶端憑證對資源所有者而言是很容易訪問的（并且經常是可見的）。由于這類應用程序駐留在用戶代理中，因此在請求授權時可以無縫利用用戶代理的功能。
native application
本地應用是指在資源所有者設備上安裝并執行的應用，協議的數據和客戶端憑證對資源所有者是可見的，可以假設該應用程序中的客戶端認證憑證都是可以被提取的。另一方面，動態簽發的憑證，比如訪問令牌或刷新令牌，是可以受到可接受程度的保護的。至少，應保護這些憑據不受應用程序可能與之交互的敵對服務器的攻擊。在某些平臺上，可以保護這些憑據免受駐留在同一設備上的其他應用程序的攻擊。
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.
不建議使用兩個參數在請求正文中包含客戶端憑據，并且應僅限于無法直接使用HTTP Basic身份驗證方案（或其他基于密碼的HTTP身份驗證方案）的客戶端。參數只能在請求正文中傳輸，并且不得包含在請求URI中。
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.
例如，在刷新access token請求的請求體中包含參數的情況：
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
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
使用密碼進行認證時，授權服務器必須按照1.6章節中所述使用TLS。
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 客戶端認證 - 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 Basic認證方案來對與授權服務器進行認證，客戶端憑證使用附錄B中定義的"application/x-www-form-urlencoded"算法進行編碼，并將編碼后的結果作為用戶名使用，客戶端密碼也是使用同樣的算法進行編碼，編碼后的結果作為密碼使用。授權服務器必須支持HTTP Basic身份驗證方案，以對發布了客戶端密碼的客戶端進行身份驗證。
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.
比如（換行符僅用于展示目的）：
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
For example (with extra line breaks for display purposes only):
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
或者，授權服務器也可以支持通過以下參數在請求體中包含客戶端憑證：
client_id
要求。如2.2章節所述，在客戶端注冊時簽發的客戶端身份標識。
client_secret
要求。客戶端密鑰，如果客戶端密鑰是空的，那客戶端可以忽略他。
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.
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
授權過程中使用了兩個授權服務器端點：
- 授權端點： 用于客戶端通過用戶代理（譯者注：一般指瀏覽器）重定向的方式來向資源所有者索要授權許可。
- 令牌端點： 用于客戶端通過授權許可去交換訪問令牌，通常會同時進行客戶端認證。
The authorization process utilizes two authorization server endpoints
(HTTP resources):o Authorization endpoint - used by the client to obtain
authorization from the resource owner via user-agent redirection.o 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:
o 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
授權端點用于與資源所有者交互以獲取授權許可。授權服務器必須先驗證資源所有者的身份，其具體的驗證方式（如用戶名密碼登錄、session cookies等）超出了本規范的討論范圍。
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.
授權端點的URI可能包含"application/x-www-form-urlencoded"的查詢組件（[RFC3986] 章節3.4）（譯者注：query component 是URI以'?'開始，以'#'結束的部分），如果有額外的查詢參數，則必須包含這部分，相反，授權端點不得包含fragment組件（譯者注：以'#'開始直到URI尾部的部分）。
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.
由于發往授權端點的請求涉及用戶認證和明文的憑證傳輸（在HTTP響應中），因此授權服務器必須如章節1.6所述使用TLS。
Since requests to the authorization endpoint result in user
authentication and the transmission of clear-text credentials (in the
HTTP response), the authorization server MUST require the use of TLS
as described in Section 1.6 when sending requests to the
authorization endpoint.
授權服務器提供的授權端點必須支持HTTP "GET"類型的請求 [RFC2616]，同時也可以選擇支持"POST"類型的請求。
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章節所述，為擴展類型。
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.
擴展的響應類型可能會包含由空格分隔的值的列表，列表中的值是順序無關的（如，"a b"等同于"b a"），這些組合形式響應類型的意義在其各自的規范中有定義。
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.
如果授權請求中未包含"response_type"參數，或者其值是錯誤的，則授權服務器需如章節4.1.2.1所述，返回相應的錯誤響應。
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
當授權服務器完成與資源所有者的交互后，授權服務器會將資源所有者的user-agent重定向回客戶端，這個重定向的端點是客戶端注冊時發布的端點，或是在授權請求時發送的端點。
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.
重定向的URI必須是[RFC3986]中定義的絕對URI，如果需要添加額外的參數，則該端點需要包含"application/x-www-form-urlencoded"格式的查詢組件([RFC3986]章節3.4)，該端點不可包含fragement組件。
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不可用，那授權服務器需要在重定向到該端點前，提示資源所有者該動作并不安全。(如，在授權請求時展示一個警告消息)
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
授權服務器要求如下類型的客戶端登記他們的重定向端點：
- 公開客戶端
- 使用隱式授權模式的非公開客戶端
The authorization server MUST require the following clients to
register their redirection endpoint:o Public clients.
o 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.
授權服務器應該要求客戶端提供完成的重定向URI(客戶端可能會使用"state"參數來防范CSRF)。如果要求注冊完整的重定向的URI并不現實，那授權服務器必須要求注冊URI scheme、authority和path(只允許客戶端動態的修改重定向URI的查詢組件的參數)。
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.
缺乏對重定向URI的注冊管理機制，可能導致如10.15章節所描述的攻擊者使用授權端點作為公共轉向器的問題(譯者注：不準確)。
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
在如下情況下，客戶端需要在授權請求時攜帶"redirect_uri"參數：
- 注冊了多個重定向端點
- 注冊了重定向端點的某部分(譯者注：如上所述，并未注冊完整的URI)
- 沒有注冊重定向端點
If multiple redirection URIs have been registered, if only part of
the redirection URI has been registered, or if no redirection URI has
been registered, the client MUST include a redirection URI with the
authorization request using the "redirect_uri" request parameter.
如果注冊過重定向URI，那當授權請求中包含重定向URI(或URI組件)時，授權服務器必須將接收到的值與注冊值進行對比(如[RFC3986]第6章節所定義)，如果客戶端注冊的是完整的重定向URI，那授權服務器應如[RFC3986]第6.2.1章節所述對其進行簡單的字符串對比校驗。
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而導致失敗，則授權服務器必須提示資源所有者失敗原因，而非自動將user-agent重定向到無效的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的形式，由user-agent處理，如果該HTML響應是直接作為重定向請求的結果，那么該HTML中包含的腳本將有權限訪問該重定向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.
3.2 Token端點 - Token Endpoint
Token端點用于讓客戶端獲取access token，可以通過出示授權許可和refresh token兩種形式。除隱式授權模式外(直接簽發access token)，其余授權模式都會使用token端點。
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).
關于客戶端如何獲取token端點的地址的問題，超出了該文檔的討論范圍，但一般是由服務目錄提供。
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.
該端點的URI如需攜帶參數，則需包含"application/x-www-form-urlencoded"格式的查詢組件([RFC3986] 3.4章節)，該端點不允許包含fragment組件。
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.
由于訪問token端點的請求或響應都涉及明文憑證的傳輸，因此必須對token端點使用1.6章節所述的TLS連接。
Since requests to the token endpoint result in the transmission of
clear-text credentials (in the HTTP request and response), the
authorization server MUST require the use of TLS as described in
Section 1.6 when sending requests to the token endpoint.
客戶端必須使用"POST"方式來發起獲取access token的請求。
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
非公開客戶端或其它簽發了客戶端憑證的客戶端，在訪問token端點時必須如章節2.3所述由授權服務器進行客戶端認證，客戶端認證的作用是：
- 確保refresh token和授權碼確實是由簽發的客戶端來使用的。當在不受信的鏈路傳輸授權碼，或者未注冊完整的重定向URI的場景下，客戶端驗證尤為重要。
- 通過禁用客戶端或修改客戶端的憑證來恢復被入侵的客戶端，從而防止攻擊者濫用竊取的refresh token。修改一組客戶端憑證顯然比撤銷整組刷新令牌要快得多。
- 實施認證管理的最佳實踐，是定期進行憑證的輪換。整套刷新令牌的輪換可能具有挑戰性，而單套客戶端憑證的輪換則容易得多。
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:o Enforcing the binding of refresh tokens and authorization codes to
the client they were issued to. Client authentication is critical
when an authorization code is transmitted to the redirection
endpoint over an insecure channel or when the redirection URI has
not been registered in full.o Recovering from a compromised client by disabling the client or
changing its credentials, thus preventing an attacker from abusing
stolen refresh tokens. Changing a single set of client
credentials is significantly faster than revoking an entire set of
refresh tokens.o 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.
當向token端點發送請求時，客戶端必須使用"client_id"參數來標識自己，當grant_type為authorization_code時，未認證的客戶端必須發送"client_id"參數來防止它接收到其它client的code，這可以保證客戶端不會被替換code(沒有為受保護的資源提供額外的安全保障)。
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"相應參數來指明為客戶端簽發的access token的授權訪問范圍。
The authorization and token endpoints allow the client to specify the
scope of the access request using the "scope" request parameter. In
turn, the authorization server uses the "scope" response parameter to
inform the client of the scope of the access token issued.
scope參數的值是空格分割且大小寫敏感的字符串，這些字符串的值是有授權服務器定義的，如果scope的值包含多個空格分割的字符串，那這些字符串值是順序無關的，并且所有的字符串都會為請求的作用域增加額外的訪問范圍。
The value of the scope parameter is expressed as a list of space-
delimited, case-sensitive strings. The strings are defined by the
authorization server. If the value contains multiple space-delimited
strings, their order does not matter, and each string adds an
additional access range to the requested scope.
scope = scope-token ?*( SP scope-token )
scope-token = 1*?( %x21 / %x23-5B / %x5D-7E )
授權服務器可以根據授權服務器策略或資源所有者的指示，完全或部分的忽略客戶端請求的作用域，如果發出的訪問令牌范圍與客戶端請求的范圍不同，則授權服務器必須包含"scope"響應參數，以告知客戶端實際授予的范圍。
The authorization server MAY fully or partially ignore the scope
requested by the client, based on the authorization server policy or
the resource owner's instructions. If the issued access token scope
is different from the one requested by the client, the authorization
server MUST include the "scope" response parameter to inform the
client of the actual scope granted.
如果客戶端在授權時忽略了scope參數，則授權服務器必須用預定義的默認值來填充，或直接告知客戶端使用了無效的scope。如有定義，授權服務器需要注明其對scope的要求和默認值。
If the client omits the scope parameter when requesting
authorization, the authorization server MUST either process the
request using a pre-defined default value or fail the request
indicating an invalid scope. The authorization server SHOULD
document its scope requirements and default value (if defined).
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
授權碼模式可用于同時獲取訪問令牌和刷新令牌，對非公開客戶端也有所優化。由于該模式依賴重定向，因此客戶端必須具備同資源所有者的user-agent(典型的如web瀏覽器)交互的能力，同時也要具備接收授權服務器請求的能力(通過重定向)。
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.
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI ---->| |
| User- | | Authorization |
| Agent -+----(B)-- User authenticates --->| Server |
| | | |
| -+----(C)-- Authorization Code ---<| |
+-|----|---+ +---------------+
| | ^ v
(A) (C) | |
| | | |
^ v | |
+---------+ | |
| |>---(D)-- Authorization Code ---------' |
| Client | & Redirection URI |
| | |
| |<---(E)----- Access Token -------------------'
+---------+ (w/ Optional Refresh Token)
圖3中的圖示包含如下步驟：
(A) 客戶端通過將資源所有者的user-agent重定向到授權端點來初始化授權碼流程，客戶端需要攜帶客戶端標識、請求授權的范圍、state以及重定向URI（當授權通過或拒絕時，授權服務器將user-agent重定向回該URI）。
(B) 授權服務器對資源所有者進行認證，并確認資源所有者是授權還是拒絕客戶端的訪問請求。
(C) 假設資源所有者授權允許客戶端的訪問，授權服務器會將user-agent重定向到之前提供的重定向URI（授權請求中或者客戶端注冊時提供的），重定向URI中會包含授權碼，以及之前客戶端提供的state參數。
(D) 客戶端通過上述步驟中獲取的授權碼，向授權服務器請求訪問令牌。當發起該請求時，客戶端需要進行身份認證，此外，參數中也需要包含換取授權碼時攜帶的重定向URI，以作為驗證。
(E) 授權服務器對客戶端進行認證，驗證授權碼是否正確，并確保重定向URI與步驟C中的完全匹配，如果驗證通過，授權服務器將返回訪問令牌，也可能包含刷新令牌。
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
客戶端使用附錄B中說明的"application/x-www-form-urlencoded"格式，去構造授權端點的請求參數：
response_type
必須。值必須為"code"。
client_id
必須。章節2.2中描述的客戶端標識。
redirect_uri
可選。章節3.1.2中有描述。
scope
可選。章節3.3中描述的請求訪問的范圍。
state
建議。客戶端用來維護請求和回調之間狀態的不透明值。授權服務器將user-agent重定向回客戶端時會攜帶該值。該值一般用于防止章節10.12中的跨站請求偽造攻擊。
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.
客戶端通過HTTP重定向的響應或其它可行的方式，將資源所有者的user-agent引導到構造的URI。
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.
比如，客戶端引導user-agent通過TLS發起如下請求：
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
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).
當用戶完成其授權決策后，授權服務器將通過HTTP重定向或其它可行的方式，將user-agent引導到重定向URI。
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
必須。該值為客戶端發起授權請求時傳遞的值（有傳則在此時返回）。
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.
例如，授權服務器會通過如下HTTP響應對user-agent進行重定向動作：
HTTP/1.1 302 Found
Location: client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
&state=xyz
For example, the authorization server redirects the user-agent by
sending the following HTTP response:HTTP/1.1 302 Found Location: client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA &state=xyz
客戶端必須忽略無法識別的響應參數。此規范未定義授權碼字符串的長度，因此客戶端應避免預設授權碼的長度。授權服務器應該記錄所有簽發的值的長度。
The client MUST ignore unrecognized response parameters. The
authorization code string size is left undefined by this
specification. The client should avoid making assumptions about code
value sizes. The authorization server SHOULD document the size of
any value it issues.
4.1.2.1 錯誤響應 - Error Response
如果授權請求由于重定向URI或客戶端標識參數存在問題（丟失、無效或不匹配）導致請求失敗，授權服務器應該告知資源所有者出現異常，而不是自動將user-agent重定向到無效的重定向URI。
If the request fails due to a missing, invalid, or mismatching
redirection URI, or if the client identifier is missing or invalid,
the authorization server SHOULD inform the resource owner of the
error and MUST NOT automatically redirect the user-agent to the
invalid redirection URI.
如果資源所有者拒絕授權，或出現除丟失、無效重定向URI以外的異常，授權服務器應該通過附錄B描述的"application/x-www-form-urlencoded"格式，通過以下參數告知客戶端異常原因：
error
必須。值為如下簡單的ASCII錯誤碼：
invalid_request
缺少必須的參數，包含無效的參數值，使用同名參數，以及其它問題。
unauthorized_client
客戶端沒有使用該方法獲取授權碼的權限。
access_denied
資源所有者拒絕授權。
unsupported_response_type
授權服務器不支持通過該方法獲取授權碼。
invalid_scope
請求的授權范圍無效或未定義。
server_error
授權服務器發生意外情況，無法完成請求（之所以需要該錯誤代碼，是因為無法通過HTTP重定向將500內部服務器錯誤狀態返回給客戶端）。
temporarily_unavailable
由于服務器臨時過載或維護，授權服務器當前無法處理該請求（之所以需要該錯誤代碼，是因為無法通過HTTP重定向將503服務器不可用狀態返回給客戶端）。
error參數值包含的字符必須在%x20-21 / %x23-5B / %x5D-7E范圍內。
error_description
可選。可理解的ASCII文本，用于提供額外的信息，幫助客戶端開發者理解發生了何種異常。
error_description參數值包含的字符必須在%x20-21 / %x23-5B / %x5D-7E范圍內。
error_uri
可選。包含錯誤信息的web界面的URI，用于向客戶端開發人員提供額外的錯誤信息。
error_uri參數值必須符合URI-reference語法，并且包含的字符必須在%x21 / %x23-5B / %x5D-7E范圍內。
state
如果客戶端在授權請求中攜帶該參數，則必須原樣返回。
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.
比如，授權服務器通過如下HTTP響應對user-agent進行重定向：
HTTP/1.1 302 Found
Location: client.example.com/cb?error=access_denied&state=xyz
For example, the authorization server redirects the user-agent by
sending the following HTTP response:HTTP/1.1 302 Found
Location: client.example.com/cb?error=access_denied&state=xyz
4.1.3 訪問令牌請求 - Access Token Request
客戶端按照附錄B中的"application/x-www-form-urlencoded"格式組織如下參數，并使用UTF-8編碼后放在HTTP請求體中，發送到token端點：
grant_type
必須。值必須為"authorization_code"。
code
必須。授權服務器返回的授權碼。
redirect_uri
必須。如果授權請求中有攜帶redirect_uri參數，那跟此次的值必須完全一致。
client_id
必須，如果客戶端如章節3.2.1所述未進行認證。
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 3.2.1.
如果客戶端類型是非公開客戶端，或者有簽發過客戶端憑證（或其它認證方式），那客戶端必須如章節3.2.1中所述與授權服務器進行認證。
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.
比如，客戶端通過TLS發送如下請求：
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
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
授權服務器必須：
- 要求客戶端進行認證（非公開客戶端、簽發過客戶端憑證的客戶端以及有其它認證要求的客戶端）。
- 如果包含客戶端認證信息，則進行認證，
- 確保授權碼是簽發給當前已認證的非公開客戶端，如果客戶端類型為公開客戶端，則確保授權碼是簽發給請求中的client_id指定的客戶端。
- 驗證授權碼的有效性，并且：
- 如果授權請求中包含redirect_uri參數，則此處也必須包含，且值必須一致。
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,
o ensure that the authorization code was issued to the authenticated
confidential client, or if the client is public, ensure that the
code was issued to "client_id" in the request,o verify that the authorization code is valid, and
o ensure that the "redirect_uri" parameter is present if the
"redirect_uri" parameter was included in the initial authorization
request as described in Section 4.1.1, and if included ensure that
their values are identical.
4.1.4 訪問令牌響應 - Access Token Reponse
如果訪問令牌請求是有效且經過客戶端認證的，那授權服務器如章節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 client
authentication failed or is invalid, the authorization server returns
an error response as described in Section 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"
}
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的腳本語言在瀏覽器上實現。
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.
由于該模式依賴重定向，因此客戶端必須有能力與資源所有者的user-agent（如web瀏覽器）進行交互，并且有接收授權服務器請求（通過重定向）的能力。
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.
隱式授權模式并不包含客戶端認證部分，它依賴資源所有者的認證和注冊時的重定向URI。由于訪問令牌會在重定向URI中，因此它可能會暴露給資源所有者或在同一設備的其它應用程序。
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.
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI --->| |
| User- | | Authorization |
| Agent -|----(B)-- User authenticates -->| Server |
| | | |
| |<---(C)--- Redirection URI ----<| |
| | with Access Token +---------------+
| | in Fragment
| | +---------------+
| |----(D)--- Redirection URI ---->| Web-Hosted |
| | without Fragment | Client |
| | | Resource |
| (F) |<---(E)------- Script ---------<| |
| | +---------------+
+-|--------+
| |
(A) (G) Access Token
| |
^ v
+---------+
| |
| Client |
| |
+---------+
圖4中包含如下步驟：
(A) 客戶端通過將資源所有者的user-agent重定向到授權端點來初始化授權流程，客戶端需要攜帶客戶端標識、請求授權的范圍、state以及重定向URI（當授權通過或拒絕時，授權服務器將user-agent重定向回該URI）。
(B) 授權服務器對資源所有者進行認證，并確認資源所有者是授權還是拒絕客戶端的訪問請求。
(C) 假設資源所有者同意授權，那授權服務器將使用之前提供的重定向URI將user-agent重定向回客戶端。在重定向URI的fragment部分會包含訪問令牌。
(D) user-agent會遵循重定向指令，向基于web的客戶端發起請求（不包含fragment部分 [RFC2616]），frament由user-agent自行處理。
(E) 基于web的客戶端會返回一個web頁面（一般是包含內置腳本的HTML文檔），該頁面有訪問包含fragment在內的整個重定向URI的權限，并且會從fragment中獲取到訪問令牌。
(F) user-agent執行客戶端返回的腳本，用于解析獲取訪問令牌。
(G) user-agent將訪問令牌傳送給客戶端。
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.
可以從章節1.3.2和9中查閱隱式授權模式的使用背景。
可以從章節10.3和10.16中查閱使用隱式授權模式時需注意的重要安全規約。
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"格式，去構造授權端點的請求參數：
response_type
必須。值必須為"token"。
client_id
必須。章節2.2中描述的客戶端標識。
redirect_uri
可選。章節3.1.2中有描述。
scope
可選。章節3.3中描述的請求訪問的范圍。
state
建議。客戶端用來維護請求和回調之間狀態的不透明值。授權服務器將user-agent重定向回客戶端時會攜帶該值。該值一般用于防止章節10.12中的跨站請求偽造攻擊。
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.
客戶端通過HTTP重定向的響應或其它可行的方式，將資源所有者的user-agent引導到構造的URI。
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.
比如，客戶端引導user-agent通過TLS發起如下請求：
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
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
授權服務器需要校驗請求中所有必須的參數是否傳入且有效，并且要校驗即將用于傳遞訪問令牌的重定向URI，是否與客戶端注冊時提供的重定向URI完全匹配（如章節3.1.2所述）。
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).
當用戶完成其授權決策后，授權服務器將通過HTTP重定向或其它可行的方式，將user-agent引導到重定向URI。
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
如果資源所有者授權了訪問請求，授權服務器需要簽發訪問令牌，并按照附錄B中的約束，將其以"application/x-www-form-urlencoded"的格式添加到重定向URI的查詢組件部分：
access_token
必須。授權服務器簽發的訪問令牌。
token_type
必須。章節7.1中描述的令牌類型，大小寫敏感。
expires_in
建議。訪問令牌的壽命，以秒為單位。比如，值為"3600"，代表訪問令牌將在響應后的一小時后過期。如果忽略該值，則授權服務器比如通過其它方式實踐過期時間，或者在文檔中明確默認的過期時間。
scope
當與請求中列舉的范圍相同時，則該返回值可選；否則必須返回，且符合章節3.3中的描述。
state
當授權請求中包含該字段時，必須原樣返回。
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.
比如，授權服務器通過如下的HTTP響應對user-agent進行重定向：
HTTP/1.1 302 Found
Location: example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
&state=xyz&token_type=example&expires_in=3600
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: example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA &state=xyz&token_type=example&expires_in=3600
開發者必須注意，某些user-agent并不支持在HTTP的Location頭中包含fragment組件，這一類的客戶端不能使用3xx重定向響應，而是需要提供其它方式對user-agent進行重定向，比如返回一個包含'continue'按鈕的HTML頁面，在點擊后跳轉到重定向URI。
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或客戶端標識參數存在問題（丟失、無效或不匹配）導致請求失敗，授權服務器應該告知資源所有者出現異常，而不是自動將user-agent重定向到無效的重定向URI。
If the request fails due to a missing, invalid, or mismatching
redirection URI, or if the client identifier is missing or invalid,
the authorization server SHOULD inform the resource owner of the
error and MUST NOT automatically redirect the user-agent to the
invalid redirection URI.
如果資源所有者拒絕授權，或出現除丟失、無效重定向URI以外的異常，授權服務器應該通過附錄B描述的"application/x-www-form-urlencoded"格式，通過以下參數告知客戶端異常原因：
error
必須。值為如下簡單的ASCII錯誤碼：
invalid_request
缺少必須的參數，包含無效的參數值，使用同名參數，以及其它問題。
unauthorized_client
客戶端沒有使用該方法獲取訪問令牌的權限。
access_denied
資源所有者拒絕授權。
unsupported_response_type
授權服務器不支持通過該方法獲取訪問令牌。
invalid_scope
請求的授權范圍無效或未定義。
server_error
授權服務器發生意外情況，無法完成請求（之所以需要該錯誤代碼，是因為無法通過HTTP重定向將500內部服務器錯誤狀態返回給客戶端）。
temporarily_unavailable
由于服務器臨時過載或維護，授權服務器當前無法處理該請求（之所以需要該錯誤代碼，是因為無法通過HTTP重定向將503服務器不可用狀態返回給客戶端）。
error參數值包含的字符必須在%x20-21 / %x23-5B / %x5D-7E范圍內。
error_description
可選。可理解的ASCII文本，用于提供額外的信息，幫助客戶端開發者理解發生了何種異常。
error_description參數值包含的字符必須在%x20-21 / %x23-5B / %x5D-7E范圍內。
error_uri
可選。包含錯誤信息的web界面的URI，用于向客戶端開發人員提供額外的錯誤信息。
error_uri參數值必須符合URI-reference語法，并且包含的字符必須在%x21 / %x23-5B / %x5D-7E范圍內。
state
如果客戶端在授權請求中攜帶該參數，則必須原樣返回。
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.
比如，授權服務器通過如下HTTP響應對user-agent進行重定向：
HTTP/1.1 302 Found
Location: client.example.com/cb#error=access_denied&state=xyz
For example, the authorization server redirects the user-agent by
sending the following HTTP response:HTTP/1.1 302 Found
Location: client.example.com/cb#error=access_denied&state=xyz
4.3 資源所有者密碼憑證模式 - Resource Owner Password Credentials Grant
資源所有者密碼模式，適用于當資源所有者與客戶端具有良好信任關系的場景，比如客戶端是設備的操作系統或具備高權限的應用。授權服務器在開放此種授權模式時必須格外小心，并且只有在別的模式不可用時才允許這種模式。
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.
該模式適用于客戶端有能力獲取資源所有者的憑證（用戶名密碼，典型的通過交互式表單來獲取）的場景，同時，也適用于現存的通過HTTP Basic或Digest模式進行認證的客戶端，想遷移到OAuth的場景（通過已存儲的資源所有者的憑證來換取訪問令牌）。
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.
+----------+
| Resource |
| Owner |
| |
+----------+
v
| Resource Owner
(A) Password Credentials
|
v
+---------+ +---------------+
| |>--(B)---- Resource Owner ------->| |
| | Password Credentials | Authorization |
| Client | | Server |
| |<--(C)---- Access Token ---------<| |
| | (w/ Optional Refresh Token) | |
+---------+ +---------------+
圖5中包含如下步驟：
(A) 資源所有者向客戶端提供自己的用戶名和密碼。
(B) 客戶端通過使用資源所有者的用戶名和密碼來訪問授權服務器的令牌端點，以獲取訪問令牌。當發起該請求時，授權服務器需要認證客戶端的身份。
(C) 授權服務器驗證客戶端身份，同時也驗證資源所有者的憑據，如果都通過，則簽發訪問令牌。
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"進行拼裝，并以UTF-8進行編碼，放置在HTTP的請求體中，來訪問令牌端點：
grant_type
必須。值為"password"。
username
必須。資源所有者的用戶名。
password
必須。資源所有者的密碼。
scope
可選。如章節3.3中描述的請求范圍。
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.
如果客戶端類型為非公開客戶端，或者簽發過客戶端憑證（或需要滿足其它的認證要求），那授權服務器需要如3.2.1中描述，對客戶端進行驗證。
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.
比如，客戶端通過TLS發起如下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
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=password&username=johndoe&password=A3ddj3w
授權服務器必須：
- 要求非公開客戶端或簽發了客戶端憑據的客戶端進行認證。
- 對需要認證的客戶端進行認證。
- 通過已有的密碼處理算法，驗證資源所有者的密碼憑據。
The authorization server MUST:
o require client authentication for confidential clients or for any
client that was issued client credentials (or with other
authentication requirements),o authenticate the client if client authentication is included, and
o validate the resource owner password credentials using its
existing password validation algorithm.
由于token請求涉及資源所有者的密碼，因此授權服務器需要保護其免受暴力破解攻擊。
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的描述返回適當的錯誤信息。
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.
成功的響應案例如下：
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"
}
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
客戶端可以僅通過客戶端憑證（或其它受支持的認證方式）來請求訪問令牌，用于訪問其可控范圍內的受保護資源，此外，也可以訪問跟其他的與授權服務器提前協商好的資源所有者的受保護資源（超出本規范的討論范圍）。
The client can request an access token using only its client
credentials (or other supported means of authentication) when the
client is requesting access to the protected resources under its
control, or those of another resource owner that have been previously
arranged with the authorization server (the method of which is beyond
the scope of this specification).
只有非公開客戶端，才能使用客戶端憑證授權方式。
The client credentials grant type MUST only be used by confidential
clients.
+---------+ +---------------+
| | | |
| |>--(A)- Client Authentication --->| Authorization |
| Client | | Server |
| |<--(B)---- Access Token ---------<| |
| | | |
+---------+ +---------------+
圖6包含如下步驟：
(A) 客戶端向授權服務器發起認證并請求獲取訪問令牌。
(B) 授權服務器驗證客戶端身份，如果通過，則簽發訪問令牌。
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 授權請求和響應 - Autorization Request and Response
使用客戶端憑證模式時，不需要發起授權請求。
Since the client authentication is used as the authorization grant,
no additional authorization request is needed.
4.4.2 訪問令牌請求
客戶端需要如附錄B中的描述，將如下參數按照"application/x-www-form-urlencoded"進行拼裝，并以UTF-8進行編碼，放置在HTTP的請求體中，來訪問令牌端點：
grant_type
必須。值為"client_credentials"。
scope
可選。如章節3.3所述的請求范圍。
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.
客戶端需要如章節3.2.1所述進行客戶端認證。
The client MUST authenticate with the authorization server as
described in Section 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=client_credentials
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 訪問令牌響應
如果訪問令牌請求有效且授權通過，則授權服務器按照5.1所述簽發訪問令牌（不得簽發刷新令牌）。如果請求無效或授權失敗，則如5.2所述返回錯誤響應。
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.
4.5 擴展授權模式 - Extension Grants
客戶端通過將令牌端點的grant_type參數聲明為一個URI（由授權服務器定義）來使用擴展模式，同時可以增加一些必要的可選參數。
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.
比如，通過使用[OAuth-SAML2]定義的SAML2.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-
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-
如果訪問令牌請求有效且授權通過，則授權服務器按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. 簽發訪問令牌 - 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
授權服務器簽發訪問令牌和可選的刷新令牌，其響應結構是將如下參數組織到HTTP響應的消息體中，并返回200響應碼：
access_token
必須。授權服務器簽發的訪問令牌。
token_type
必須。如章節7.1所述，標識簽發的令牌的類型，大小寫敏感。
expires_in
建議。訪問令牌的壽命，以秒為單位。比如，值為"3600"，代表訪問令牌將在響應后的一小時后過期。如果忽略該值，則授權服務器比如通過其它方式實踐過期時間，或者在文檔中明確默認的過期時間。
refresh_token
可選。刷新令牌，使用章節6中描述的授權方式來獲取新的訪問令牌。
scope
當與請求中列舉的范圍相同時，則該返回值可選；否則必須返回，且符合章節3.3中的描述。
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.
參數應如[RFC4627]中所描述的，使用"application/json"媒體類型，并置于HTTP響應的響應體中。這些參數會被序列化為JSON格式，如上的參數都置于JSON的頂級。參數名和參數值都作為JSON字符串，數值類型的參數值作為JSON數字。這些參數排列的順序無關。
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.
授權服務器必須包含"Cache-Control"響應頭，對所有包含令牌、憑證和其它敏感信息的響應，都需要將其值設置為"no-store"，同樣的，"Pragma"響應頭也要設置為"no-cache"。
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".
舉例如下：
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"
}
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
授權服務器返回400（Bad Request）響應碼（除非另有聲明）以及如下響應參數：
error
必須。值為如下簡單的ASCII錯誤碼：
invalid_request
請求丟失必要的參數，或包含不支持的參數（超出授權類型規約的），或使用重復的參數，或包含多種憑證，或使用多種機制進行客戶端認證，以及其它的問題。
invalid_client
客戶端認證失敗（如，未知的客戶端、沒有包含客戶端認證信息、不支持的認證方式等）。授權服務器可能返回401響應碼來指明支持何種類型的HTTP認證方式。如果客戶端希望通過Authorization請求頭進行認證，那授權服務器必須返回401響應，并包含WWW-Autoenticate響應頭來指明客戶端使用的認證方式。
invalid_grant
采用的授權方式或刷新令牌是無效的、過期的、已吊銷的、重定向URI不匹配以及是簽發給其它客戶端的等等。
unauthorized_client
已認證的客戶端沒有使用此種授權模式的權限。
unsupported_grant_type
授權服務器不支持此種授權模式。
invalid_scope
請求的授權范圍是無效的、未知的，或超出資源所有者的授權范圍。
error參數值包含的字符必須在%x20-21 / %x23-5B / %x5D-7E范圍內。
error_description
可選。可理解的ASCII文本，用于提供額外的信息，幫助客戶端開發者理解發生了何種異常。
error_description參數值包含的字符必須在%x20-21 / %x23-5B / %x5D-7E范圍內。
error_uri
可選。包含錯誤信息的web界面的URI，用于向客戶端開發人員提供額外的錯誤信息。
error_uri參數值必須符合URI-reference語法，并且包含的字符必須在%x21 / %x23-5B / %x5D-7E范圍內。
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.
參數應如[RFC4627]中所描述的，使用"application/json"媒體類型，并置于HTTP響應的響應體中。這些參數會被序列化為JSON格式，如上的參數都置于JSON的頂級。參數名和參數值都作為JSON字符串，數值類型的參數值作為JSON數字。這些參數排列的順序無關。
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.
舉例如下：
HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"error":"invalid_request"
}
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"格式組織如下參數，并使用UTF-8進行編碼后放入HTTP請求體。將請求發送至token端點以刷新訪問令牌：
grant_type
必須。值必須為"refresh_token"。
refresh_token
必須。簽發給客戶端的刷新令牌。
scope
可選。章節3.3中描述的請求授權的范圍，scope的值不能包括最初資源所有者未授權的值，如果忽略該參數，則視為與資源所有者最初授權的值相同。
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.
由于刷新令牌是用于請求額外訪問令牌的長時效令牌，因此刷新令牌需要跟客戶端做綁定。如果客戶端類型是非公開客戶端或者簽發過客戶端憑證（或其它認證方式），則授權服務器必須如章節3.2.1所述對客戶端身份進行校驗。
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.
比如，客戶端通過TLS發起如下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
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:
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
ensure that the refresh token was issued to the authenticated
client, ando validate the refresh token.
如果驗證且授權通過，則授權服務器按5.1所述簽發訪問令牌，如果驗證失敗或無效，則如5.2所述返回錯誤響應。
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
客戶端通過向資源服務器出示訪問令牌來訪問受保護資源。資源服務器必須檢驗該訪問令牌，確保其未過期，且授權的scope可以訪問當前請求的資源。資源服務器如何校驗訪問令牌超出了本規范要討論的范圍，但一般是通過與授權服務器之間進行交互協作來實現。
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.
客戶端如何使用訪問令牌與資源服務器進行認證，取決于授權服務器簽發的訪問令牌的類型。一般來說，會使用[RFC2617]中提及的HTTP的"Authorization"請求頭，配合所使用的訪問令牌類型的相關規范文檔中定義的認證方案來協調實現，如[RFC6750]。
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
訪問令牌的類型能告知客戶端如何成功使用訪問令牌訪問受保護資源，如果客戶端不清楚訪問令牌的類型，則不得使用該訪問令牌。
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.
比如，[RFC6750]中定義的bearer令牌類型，通過簡單的將訪問令牌包含到如下請求中進行使用：
GET /resource/1 HTTP/1.1
Host: example.com
Authorization: Bearer mF_9.B5f-4.1JqM
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
當使用[OAuth-HTTP-MAC]中定義的mac令牌類型時，通過對HTTP請求中的主要組件進行簽名（消息認證碼），來與訪問令牌配合使用：
GET /resource/1 HTTP/1.1
Host: example.com
Authorization: MAC id="h480djs93hd8",
nonce="274312:dj83hs9s",
mac="kDZvddkndxvhGRXZhvuDjEWhGeE="
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="
如上的僅作為示例，開發者在實際使用前，請參考[RFC6750]and[OAuth-HTTP-MAC]規范。
The above examples are provided for illustration purposes only.
Developers are advised to consult the [RFC6750] and [OAuth-HTTP-MAC]
specifications before use.
所有訪問令牌類型的聲明，都必須說明與access_token配合使用的額外的參數（如果有）。它同時也定義當訪問受保護資源時，應該采用何種HTTP認證方式來攜帶訪問令牌。
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令牌認證方案的錯誤值建立了一個共享的注冊表。
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.
如果新的認證方案主要是為OAuth令牌認證方案設計的，那么應該定義一種向客戶端提供錯誤狀態碼的機制，在該機制中，錯誤碼應注冊在本規范建立的共享注冊表中。
New authentication schemes designed primarily for OAuth token
authentication SHOULD define a mechanism for providing an error
status code to the client, in which the error values allowed are
registered in the error registry established by this specification.
這類方案可以將有效的錯誤狀態碼設置為已注冊項的子集。如果使用命名參數來返回錯誤碼，參數名應該為error。
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".
如果認證方案有能力作為OAuth令牌認證方案，但主要不是為此設計的，也可以用同樣的方式將自己的錯誤碼綁定到注冊表中。
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.
新的認證方案也可以選擇使用error_description和error_uri參數，以與本規范中error參數平行的方式返回錯誤信息。
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；
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.
使用URI名稱的令牌類型，應限制為特定的供應商的實現，這些實現通常是不通用的，且僅特定于使用它們的資源服務器。
Types utilizing a URI name SHOULD be limited to vendor-specific
implementations that are not commonly applicable, and are specific to
the implementation details of the resource server where they are
used.
其余的令牌類型都應該注冊到注冊表。類型名稱必須遵循type-name范式，如果該類型定義包含HTTP認證方案，則類型名稱必須與HTTP認證方案相同（如[RFC2617]所定義），"example"這種類型作為示例中的保留類型。
type-name = 1*name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA
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 Parameters注冊表中定義和注冊。
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.
參數名必須遵循param-name范式，并且參數值的語法也需要被明確定義（比如，使用ABNF，或者指向已存在參數的語法的引用）。
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
未注冊的、限制于供應商的參數擴展通常不具備適用性，并且受限于使用他們的授權服務器。這些參數通常可以加多一個命名前綴，以避免與其它注冊值沖突（比如，使用'companyname_'前綴）。
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
可以通過為grant_type參數指定唯一的絕對URI路徑，來定義新的授權流程。如果這個擴展的授權類型需要在令牌端點使用額外的參數，那必須如章節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中的流程，注冊到Authorization Endpoint Response Types注冊表中。響應類型名稱比如遵循如下范式：
response-type = response-name *( SP response-name )
response-name = 1*response-char
response-char = "_" / DIGIT / ALPHA
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.
比如，響應類型"token code"在本規范中并未定義，因此可以將其定義為擴展的響應類型，一旦注冊，那與其順序不同的"code token"就不能再注冊為新的響應類型，但這兩個順序不同的值都可以同時用來表明同一種響應類型。
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 - 定義額外的錯誤碼
當進行協議擴展時（訪問令牌類型擴展、參數擴展以及授權類型擴展等），如果需要額外的錯誤碼與授權碼流程錯誤碼、隱式授權模式錯誤碼、令牌錯誤響應以及資源訪問錯誤響應等配合使用，那這些額外的錯誤碼需要進行定義。
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.
如果擴展的錯誤碼需要與已注冊的令牌類型、已注冊的端點參數或者一個擴展的授權類型一起使用，那該錯誤碼必須進行注冊（遵循章節11.4）。如果與未注冊的擴展點配合使用，則可注冊也可不注冊。
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.
錯誤碼必須遵循如下ABNF的范式，如果可能，那在該范式前再增加一個標識前綴。比如，為"example"這個擴展參數增加的標識其無效的擴展錯誤碼，則可以命名為"example_invalid"。
error = 1*error-char
error-char = %x20-21 / %x23-5B / %x5D-7E
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
本地應用是指在資源所有者所使用的設備上安裝并執行的客戶端（比如桌面應用、手機應用等），本地應用要求額外的有關安全性、平臺適應性以及用戶體驗方面的考量。
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.
授權端點涉及到客戶端和資源所有者的user-agent之間的監護，本地應用客戶通過打開外部的user-agent或者應用內置一個user-agent來解決。
比如：
- 外部的user-agent - 本地應用可以通過這些方法來使用重定向URI，以獲取授權服務器的響應。如通過在操作系統層面將應用注冊為處理器、手動復制粘貼憑證、運行一個本地的web服務器、安裝user-agent擴展插件、或者提供一個在客戶端掌控下的重定向URI，從而使響應對本機應用程序可用。
- 內置user-agent - 通過與內置瀏覽器的通訊，本地應用可以獲取響應，比如當資源加載時監控狀態變化，或者訪問user-agent的cookies。
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.
關于如何選擇使用外部或內置的user-agent，開發者可考慮如下要素：
- 外部的user-agent可能會提高完成效率，因為資源所有者可能已經在該user-agent中存在有效的會話，無需再次進行認證，這為最終用戶提供了統一的體驗和功能。資源所有者還可以依賴user-agent的特性和擴展來幫助進行身份認證（比如密碼管理器、雙因素設備讀取器）。
- 內嵌的user-agent可能會提高可用性，因為它無需在新窗口打開，也不涉及上下文的切換。
- 內嵌的user-agent會導致一些安全問題，因為資源所有者會在一個未識別的窗口中進行認證，該窗口無法提供大部分外部user-agent鎖支持的保護策略。內嵌的user-agent可能會教導最終用戶習慣性信任一些未識別的認證請求（導致更容易進行釣魚攻擊）。
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.
