The Oauth2.0 Authorization Framework翻译part1

前言：最近项目里面要搭建OAuth2.0服务，网上搜寻一番后发现大部分中文文章都是关于如何在客户端中使用OAUth2.0服务，对OAuth的验证服务器和OAuth原理与意图介绍的不多，所以翻译一下OAuth2.0的官方规格说明书（http://tools.ietf.org/html/rfc6749），以加深理解

概述

　　The OAuth 2.0 认证框架使第三方应用受限的访问http服务成为了可能，实现方式有两种，一种是通过精心策划的资源拥有者和http服务之间的交互式批准授权，另一种是允许第三方代表自己获取访问权限

1.Introduce

　　在传统的客户端-服务器认证模型中，客户端通过资源拥有者的认证信息请求一个访问受限(受保护的)的资源，为了给第三方应用提供受限资源，资源拥有者与第三方分享他的认证信息，这引起了一些问题和限制。

• 第三方应用为了将来的访问需要存储资源拥有者的认证信息。大多数情况下是明文密码。
• 服务器需要支持密码认证，尽管在这些密码中包含安全隐患
• 第三方应用获得了过多的访问权限，可以访问资源拥有者所有的受保护资源。使得资源拥有者没有能力限制权限的过期时间或是资源的访问范围
• 资源拥有者无法撤销某个独立第三方应用的权限，除非撤销所有第三方应用的权限，而且必须通过更改第三方应用所拥有的密码来实现这一目的。
• 对任何一个第三方应用的危害将导致对最终用户密码的危害，而所有的数据都是通过用户密码来保护的

　　OAuth通过引入一个认证层和从资源拥有者中分离客户端的角色来应对这些问题。在OAuth中，客户端对资源的访问权限被资源拥有者控制并由资源服务响应，而且Oauth发布了一个与资源拥有者认证信息不同的认证子集。

　　为了替代使用资源拥有者的认证信息访问受保护资源，客户端获取一个访问令牌--一个标示指定范围、生命周期以及其他访问属性的字符串。通过资源拥有者的批准认证服务器会把访问令牌发给客户端。客户端使用访问令牌访问资源服务器上的受保护资源。

　　例如，一个最终用户(资源拥有者)可以授权一个打印服务(客户端)访问其图片分享服务(资源服务器)上存储的图片，而且不需要把自己的用户名和密码分享给打印服务。代替的，她直接与一个受图片分享服务信任的服务器(认证服务器)进行认证。认证服务器给打印服务分发特别授权的认证信息(访问令牌)

　　本规格说明是为使用HTTP协议设计的，通过任何HTTP之外的协议使用OAuth都超出了本规格的范围。

　　OAuth 1.0协议文档的发布，是社区努力的结果。本规格建立在OAuth 1.0的发布经验之上，就像附加用例和从IETF社区获悉扩展要求。OAuth 2.0没有对OAuth 1.0做向后兼容。两种版本可能共存在网络上，而且具体实现可能会同时支持他们。然而本规格的目的时新的实现支持OAuth 2.0而Oauth 1.0只用来支持已经存在的部署。OAuth 2.0相比OAuth 1.0分享非常少的实现细节。熟悉OAuth 1.0的使用者在处理本文档时不应当对他的结构和细节做任何假定。

1.1 角色

　　OAuth定义了四种角色：

　　　　资源拥有者

　　　　　　一个有能力授权访问受保护资源的实体。当资源拥有者是一个人的时候，他被称为最终用户。

　　　　资源服务器

　　　　　　拥有受保护的资源，有能力通过使用访问令牌接受并响应一个受保护资源请求

　　　　客户端

　　　　　　一个通过资源拥有者的认证代表资源拥有者发起受保护资源请求的应用。

　　　　认证服务器

　　　　　　一个在资源拥有者成功认证后分发访问令牌给客户端的服务器

　　认证服务器和资源服务器之间的互动超出了本规格说明的范围。认证服务器可能与资源服务器是同一个服务器，也可能是分开的。一个认证服务器分发的访问令牌可能被多个资源服务器接受

1.2 协议流

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

                     图1：协议流摘要

　　图去中示范的OAuth 2.0协议流描述了四个角色之间的交互。包含一下步骤：

　　　　（A）客户端请求资源拥有者的认证，认证请求可以直接发给资源拥有者(如图所示)，或是通过认证服务器来做中介 

　　　　（B）客户端收到认证授权，此认证信息代表了资源拥有者的认证，表达使用了本规格定义的四种授权类型之一或是使用了扩展的授权类型。认证授权类型取决于客户端请求认证使用的方法和认证服务器支持的授权类型

　　　　（C）客户端通过认证服务器验证和展示认证授权来请求访问令牌

　　　　（D）认证服务器验证客户端并确认认证授权是否有效，如果有效，分发一个访问令牌

　　　　（E）客户端通过呈现访问令牌请求资源服务器的受保护资源

　　　　（F）资源服务器确认访问令牌的有效性，如果有效，处理请求

　　客户端获得资源拥有者认证授权的首选方法是用认证服务器做中介，此方法的示例在4.1节图3中

1.3 认证授权

　　认证授权是一个认证信息，它代表了资源拥有者的认证（访问他的受保护资源）被客户端用来获得访问令牌。本规格定义了四种授权类型--认证码，隐式，资源拥有者密码认证信息，和客户端认证信息--也可以扩展机制定义额外的类型

1.3.1认证码

　　认证码可以通过使用认证服务器做客户端和资源拥有者的中介来得到，代替直接请求资源拥有者得到。客户端指引资源拥有者到一个认证服务器（通过RFC2616定义的用户代理），它会反过来指引资源拥有者带着认证码返回客户端。

　　在指引资源拥有者带着认证码返回客户端之前，认证服务器鉴定资源拥有者并获得授权。因为资源拥有者只会与认证服务器进行认证，资源拥有者的认证信息永远不会与客户端分享。

　　认证码提供了一些重要的安全优势，比如不但有认证客户端的能力，还可以直接传送访问令牌给客户端，不需要通过资源拥有者的用户代理来传送这样有可能暴露给其他人，包括资源拥有者。

1.3.2 隐式

　　隐式授权可被认为是一种简单方式的认证码，它是为实现在浏览器中并使用如JavaScript等脚本语言的客户端特别优化的。在隐式流中，不再分发给客户端一个认证码，客户端被直接分发一个访问令牌(作为资源拥有者认证的结果)。授权类型时隐式的，没有中间认证信息（比如认证码）被分发

　　当在隐式授权流中分发一个访问令牌时，认证服务器不会鉴定客户端。在某些情况下，客户端的身份可以通过用来发送访问令牌到客户端的重定向URI来确定。访问令牌可能会暴露给资源拥有者或是其他可以访问资源拥有者的用户代理的程序。

　　隐式授权增强了一些客户端的响应能力和效率（比如实现在浏览器内的应用），因为它减少了获取访问令牌的请求响应次数。然而，这种便利应该被小心权衡，就像10.3节和10.16节中描述的例子，特别是当认证码授权类型可用的时候。

1.3.3资源拥有者密码认证信息

　　资源拥有者密码认证信息（也就是，用户名和密码）可以直接用来作为认证授权从来获取访问令牌。这种认证类型应该只有在资源拥有者和客户端之间存在高等级的信任程度时（比如客户端是设备操作系统的一部分或是有很高特权的应用），而且其他的认证授权方式不可用（比如认证码）

　　即使这种授权类型需要客户端直接访问资源拥有者的认证信息，资源拥有者的认证信息仍然只在一次单独请求中使用，然后交换一个访问令牌。这种授权类型通过交换认证信息为一个长期有效的访问令牌或是刷新令牌，来避免客户端存储资源拥有者的认证信息。

1.3.4客户端认证信息

　　客户端认证信息（或客户端认证信息的其他形式）可以用来当做这样一种认证授权类型，当受保护资源的授权范围在客户端的控制之下，或是授权范围是之前与认证服务器商定的。客户端认证信息通常在客户端作用于它自己（客户端也是资源拥有者）或者正在请求的受保护资源基于一个之前与认证服务器商定的授权。

1.4 访问令牌

　　访问令牌是用来访问受保护资源的认证信息，一个访问令牌是一段代表了给客户端授权的字符串。字符串通常对客户端是不透明的。令牌代表了访问的指定范围和生命周期，它是由资源拥有者授权并由资源服务器和认证服务器来执行的。

　　令牌可能代表了可以检索授权信息的识别信息，或者可能用一种可验证的方式自包含一段授权信息（也就是，令牌字符串包含了一些数据和签名）。超过本规格的额外认证信息，可能在客户端使用令牌时才需要。

　　访问令牌提供了一个抽象层，用一个可被资源服务器理解的令牌来替代不同的认证结构（比如，用户名和密码）。这一抽象比认证授权直接获得访问令牌的方式更可控，比如资源服务器不再需要理解许多不同的认证方法。

　　认证令牌基于资源服务器的安全需要可以有不同的格式，结构和使用方法（比如，加密属性）。用来访问受保护资源的访问令牌的属性和方法，超出了本规格的范围，他们被定义于[RFC6750]这样的指导手册中。

1.5刷新令牌

刷新令牌时用来获取访问令牌的认证信息。刷新令牌时认证服务器分发给客户端的，每当当前的访问令牌失效或过期时它被用来获取一个新的访问令牌，也可以用来获取额外的一个访问令牌，这个访问令牌可以是与当前相同的，也可以具有更少的访问范围（比资源拥有者授权的访问令牌拥有更少的权限和更短的生命周期）。分发刷新令牌可以选择由认证服务器处理。如果认证服务器分发一个刷新令牌，同时也发布一个访问令牌。

　　一个刷新令牌代表了资源拥有者授权给客户端的字符串。字符串通常对客户端是不透明的。令牌表示了用来检索认证信息的标识。不像访问令牌，刷新令牌只会用于与认证服务器交流，永远不会发送给资源服务器。

+--------+                                           +---------------+
  |        |--(A)------- Authorization Grant --------->|               |
  |        |                                           |               |
  |        |<-(B)----------- Access Token -------------|               |
  |        |               & Refresh Token             |               |
  |        |                                           |               |
  |        |                            +----------+   |               |
  |        |--(C)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(D)- Protected Resource --| Resource |   | Authorization |
  | Client |                            |  Server  |   |     Server    |
  |        |--(E)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(F)- Invalid Token Error -|          |   |               |
  |        |                            +----------+   |               |
  |        |                                           |               |
  |        |--(G)----------- Refresh Token ----------->|               |
  |        |                                           |               |
  |        |<-(H)----------- Access Token -------------|               |
  +--------+           & Optional Refresh Token        +---------------+

               Figure 2: Refreshing an Expired Access Token
图2中的示例包含一下步骤：
　　（A）客户端使用认证授权通过认证服务器请求访问令牌。
　　（B）认证服务器鉴定客户端并校验认证授权，如果有效，分发一个访问令牌和刷新令牌
　　（C）客户端通过访问令牌访问资源服务器上的受保护资源
　　（D）资源服务器校验访问令牌，如果有效，处理请求
　　（E）步骤C和D直到访问令牌过期之前会一直重复。如果客户端直到访问令牌已经过期，会跳到步骤G；否则，他生成另外一个受保护资源的请求
　　（F）一旦访问令牌无效，资源服务器返回令牌无效错误
　　（G）客户端使用刷新令牌通过认证服务器请求一个新的访问令牌。客户端认证需求基于客户端类型和服务端策略
　　（H）认证服务器验证客户端和刷新令牌，如果有效，分发一个新的访问令牌（可选的，再发送一个新的刷新令牌）
步骤C,D,E,F不在本规格的范围内，同时也描述于第7节
1.6 TLS版本
　　当安全传输层协议（TLS）被本规格使用，

TLS Version

   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 Redirections

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

 

1.9. Notational Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   specification are to be interpreted as described in [RFC2119].

   This specification uses the Augmented Backus-Naur Form (ABNF)
   notation of [RFC5234].  Additionally, the rule URI-reference is
   included from "Uniform Resource Identifier (URI): Generic Syntax"
   [RFC3986].

   Certain security-related terms are to be understood in the sense
   defined in [RFC4949].  These terms include, but are not limited to,
   "attack", "authentication", "authorization", "certificate",
   "confidentiality", "credential", "encryption", "identity", "sign",
   "signature", "trust", "validate", and "verify".

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

2. 客户端注册Client Registration

　　在开始使用协议之前，客户端向认证服务器注册。客户端注册的方法超过了本规格的范围，不过通常是终端用户与html注册表交互

　　客户端注册不需要客户端与认证服务器之间的直接交互。　

   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.

To be continue........
第二部分

 

转载于:https://www.cnblogs.com/piruzhaolu/archive/2013/05/12/3074315.html