OAuth 2.0授权框架中文版 [1] - 简介

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

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

• (A) 客户端向资源所有者请求授予权限。授权请求可以由客户端直接向资源所有者发起（如图所示），或者更好的方式是由授权服务器作为中间人间接发起。

• (B) 客户端接收到的授权许可，是代表资源所有者的授权凭证（如：Authorization Code），通常采用本规范中定义的四种授权类型或其它扩展类型来获取。

• © 客户端通过与授权服务器发起身份认证以及出式授权许可，来换取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.

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

图2所示的流程包括以下步骤：

• (A) 客户端通过授权服务器进行身份验证，并提出授权许可，申请访问令牌。

• (B) 授权服务器对客户端和授权许可进行验证，如果有效，则签发访问令牌和刷新令牌。

• © 客户端通过向资源服务器出示访问令牌来访问受保护的资源。

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

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