OAuth 2.0文档翻译（第一章）

                                       OAuth 2.0 受权框架

概要

OAuth 2.0受权框架使得第三方应用得到有限的http服务，也表明了用户（资源拥有者）经过策划一个批准通讯在用户和http服务之间，或者运行第三方应用表明自身得到权限。这个说明文档取代了在RFC 5849描述的过期的OAuth 1.0协议。

这份备忘录的地位

这是一个互联网标准跟踪文档。

这份文档是IETF(Internet Engineering Task Force：互联网工程任务小组)的做品。表明了IETF团队的一致意见。接受了公共的审查而且被IESG(Internet Engineering Steering Group:互联网工程指导小组)批准发布。互联网标准更加详细信息可在Section 2 of RFC 5741获取。

第一章：介绍

在传统的client—server认证模型中，client在server端使用resource owner 的证书认证而后请求protected resource。为了使得第三方应用能访问protected resource，resource owner 和第三方分享了它的证书，可是这也产生了一些弊端：

1.第三方应用被要求存储resource owner 的证书以便未来使用，（证书）一般是明文密码。

2.服务器被要求不顾在密码方面的固有的安全缺陷，而去支持密码受权。

3.第三方应用得到过多的用户权限，使得resource owner 没法限制时长（证书有效时间）或访问一个被限制的资源子集。

4.resource owner 没办法撤销对某一个应用的访问权限必须经过改变用户帐号的密码才能实现，但这样也会撤销对其余应用的访问权限。（大概的意思是第三方帐号和密码对于全部的第三方应用都是通用的，不可能只限制某一个应用）

5.任何一个第三方应用被破解，用户密码以及相关的数据都会泄露。

OAuth 2.0 经过引入受权层和把客户端角色从用户中分离出来解决这个问题。在OAuth 2.0中，client请求访问被source owner控制、寄管在resource server上的资源。而且本分配了一系列不一样的证书。

代替使用resource owner的证书访问protected resources，client获取一个access token（任务令牌）——一个指明了特定的范围，生命周期和其余的访问属性的字符串。access token是经resource owner赞成，由authorization server分配给第三方client的。client使用access token访问被resource server 托管的资源。

例如，一个终端用户（resource owner）能够受权一个printing service（client）访问存于photo sharing service（resource server）上的protected photo，而不用把他的用户名和密码告诉printing service。相反，他能够经过一个被photo sharing service(authorization server)信任的server直接认证，server 给printing service分配一个特定受权证书（access token）。

这份文档是为使用HTTP设计的。([RFC2616]).OAuth 协议的使用暂不支持HTTP协议以外的其余协议。

OAuth 1.0协议，被做为一份报告文档发布，是一个小且特殊的团队努力的结果。这份标准追踪说明文档是创建在OAuth 1.0部署的经验以及额外的使用案例和源于更普遍的IETF(Internet Engineering Task Force:互联网工程任务小组）扩展性要求。

OAuth 2.0协议并不向后兼容OAuth 1.0协议。这两个版本共存于互联网上，并且实现可能会选择两者都支持。然而，这篇文档意在代表新的实现支持OAuth 2.0，而OAuth 1.0仅支持已经存在的实现上。OAuth 2.0和OAuth 1.0在具体的实现细节上只有不多是相同的。熟悉OAuth 1.0实现的用户无须设想OAuth 2.0是其结构和细节。

1.1 角色（roles）

OAuth定义了四种角色

用户（resource owner）

一个能受权访问protected resource的实体。当用户是我的的时候，被归为终端用户。

资源服务器（resource server）

托管protected resource资源的服务器，可以接受和使用access token（访问令牌）回应protected resource请求。

客户端（client）

使用认证表明用户发出请求protected resource的应用。关键词“client”并不包含任何特殊的实现特性（不论这个应用执行在server，desktop，仍是devices上）

认证服务器（authorization server）

当成功认证用户而且得到认证后给客户端分配access token的服务器。

认证服务器和资源服务器之间的通讯超出本文档的范围，认证服务器多是资源服务器也多是一个独立实体。一个单一的认证服务器分发access token可能会被多个资源服务器接受。

1.2 协议流（protocal flow）

　　　　　　　　　　Figure 1 抽象协议流

 

图1中阐明的抽象协议流描述了四种角色之间的通讯而且包含了一下步骤：

A：客户端（client）从用户（Resource Owner）请求受权，受权请求能够直接向用户发出，也能够更好的间接经由认证服务器做为中间件。

B：客户端（client）接收认证受权，认证受权是代表了用户受权的证书，被在这篇文档中定义了的四种受权类型之一的受权方式或者扩展的受权方式实现。受权认证的类型取决于客户端请求受权使用的方法和被认证服务器支持的类型。

C：客户端（client）经过验证认证服务器和上传受权认证（Autorization Grant）请求访问令牌（access token）。

D：认证服务器认证客户端而且判断受权认证（Autorization Grant）是否有效，若是有效，分配一个access token。

E：客户端从资源服务器请求protected resource并经过access token进行验证。

F:资源服务器判断access token是否有效，若是有效，响应请求。

客户端从用户获取受权认证（Authorization Grant）的更好的方法是使用认证服务器（Authorization Server）做为中间件，它在Section 4.1的表3中被阐明。

1.3 受权认证（Authorization Grant）

受权认证（Autorization Grant）是一种代表用户受权的证书，被客户端用来获取访问令牌（access token）。这篇文档定义了四种认证类型——受权码模式（Authorization Code），隐式受权模式（implicit），用户密码证书模式（Resource Owner Password Credentials），客户端证书模式（Client Credentials），以及定义其余类型的扩展性机制（Extensibility Mechanism）。

1.3.1: 受权码模式（Authorization Code）

受权码（Authorization Code）是使用认证服务器（Autorization Server）做为客户端(Cilent)和用户（Resource Owner）之间的中间件得到的。代替从用户（Resource Owner）直接请求受权（Autorization），客户端指导用户（Resource Owner）转到认证服务器（Outhorization Server）（经过用户代理（user-agent)（被定义在RFC2616）实现）。反过来认证服务器引导用户携带受权码（Authorization Code）返回到客户端。

在指导用户携带受权码（Autorization Code）返回客户端以前，认证服务器（Autorization Server）验证用户并得到受权。由于用户仅和认证服务器认证，而用户的受权证书并不和客户端分享。

受权码（Authorization Code）提供了一些安全好处。例如认证客户端，以及访问令牌和客户端直接通讯而无须通过用户代理且能避免信息暴露给其余用户，包括当前用户（Resource Owner）。

流程图以下：

　　　　　　　　　　Figure 2 此图参考阮一峰的博客

 流程分析：

A:用户访问客户端，客户端将用户导向认证服务器（Authorization Server）

B:用户给客户端受权

C：认证服务器验证用户的受权认证，若是认证成功的话，返回受权码（Authorization Code）

D:客户端携带受权码和重定向地址向认证服务器发出请求。

E:认证服务器验证受权码和重定向地址成功，返回token（Access Token，Refresh Token）

1.3.2 隐式受权模式（implicit）

隐式受权模式（implicit grant)是被简化的受权码流，方便客户端在浏览器使用脚本语言的实现，例如JavaScript。在隐式流（implicit flow）中，代替给客户的分配一个受权码，客户端被直接分配了一个访问令牌（access token）（用户受权的结果）。受权类型是隐式的，没有分配中间证书（例如受权码）。

在隐式流过程当中分配访问令牌时，认证服务器并不验证客户端。一些状况下，客户端身份会经由重定向地址被识别，用于传送访问令牌给客户端。访问令牌可能会暴露于用户和其余有权访问用户代理的应用。

隐式受权提高了客户端的响应能力和效率（例如客户端做为一个浏览器应用被实现）。由于他减小了为获取访问令牌执行的循环执行的数量。然而，这种便利应该与使用隐式受权带来的安全问题权衡。例如在Sections 10.3和10.16尤为当受权码受权类型是可获取的。

 

　　　　　　　　Figure 3 此图参考阮一峰的博客

流程分析：

A:用户访问客户端，客户端将用户导向认证服务器

B:用户受权客户端登陆

C:认证服务器验证用户受权认证，返回重定 向地址和访问令牌

D:客户端使用重定向地址直接请求资源服务器

E:资源服务器返回javascript脚本语言文本

F:浏览器执行脚本，提早访问令牌

 1.3.3用户密码证书模式（Resource Owner Password Credential）

用户密码证书模式能够直接被用在受权认证（Authorization Grant）得到访问令牌（Access Token），证书仅当用户高度信任应用的时候被使用（应用是设备系统的一部分或具备高级权限的应用），并且当其余受权认证类型（Authorization Grant Type）是不可实现时（例如受权码模式）。

虽然认证类型要求客户端直接访问用户证书，用户证书被用来作独立请求及交换访问令牌。这种认证类型经过使用长生命周期的访问令牌和更新令牌，能够消除客户端为未来使用存储用户信息的需求。

流程图以下：

　　　　　　　　Figure 4

流程分析：

A:用户访问应用，输入用户名和密码

B:客户端把密码证书发给认证服务器

C:认证服务器验证密码证书有效，将访问令牌和更新令牌发给客户端。

1.3.4 客户端证书模式（Client）

客户端证书模式被用作受权认证当受权范围是有限的受保护资源在客户端的控制下，或受保护资源被认证服务器预先安排好。客户端证书模式被应用典型的当客户端做用自身（客户端也是用户）或者请求访问在认证服务器预先安排好的受权基础上的资源。

　　　　　　　　Figure 5 

流程分析：

A:客户端直接向认证服务器发送身份验证，请求访问令牌

B:认证服务器返回访问令牌

 

 1.4访问令牌（Acess Token）

访问令牌时访问被保护资源的证书。访问令牌是一段表示了给客户端受权的字符串。这段字符串对客户端通常是不透明的，令牌表明了访问的范围和时间，由用户认证，被资源服务器和认证服务器执行。令牌表示被用来检索受权信息或自身包含受权信息的标识符（一段令牌字符串自己包含一些数据和签名）。额外的受权证书不在这篇文档范围以内，可能会被要求一致为了方便用户使用令牌。

访问令牌提供一个抽象层，用一个被资源服务器理解的独立令牌取代不一样的受权设计（使用用户名和密码）。这种抽象使得分配访问令牌更加受限比经过受权认证获取他们，也取消了受权服务器理解普遍受权方法的需求。

访问令牌在资源服务器安全需求上可有不一样的格式，结构和应用方法。访问令牌访问被保护数据的属性和方法超出了本文档的范围，具体可参照相关文档如RFC6750.

1.5 更新令牌（refresh token）

更新令牌时用来获取访问令牌的证书。更新令牌被认证服务器分配给客户端，被用来获取新的访问令牌当当前的访问令牌时无效或过时了的时候，或用彻底相同或更少的权限获取其余访问令牌（访问令牌可能比被用户认证具备更短的生命周期和更少的权限）。分配更新令牌在认证服务器时可选的。若是认证服务器分配一个访问令牌，它是被包括的当分配一个访问令牌时（Figure 1 ，Step D)

 一段更新令牌字符串表明了用户对客户端的受权认证。这段字符串对客户端通常都是不透明的。令牌表示被用来检索受权信息的标识符。不像访问令牌，更新令牌仅和认证服务器关联而和资源服务器无干。

流程图以下

　　　　　　　　　　Figure 6 Refresh Token & Expired Acess Token

流程分析：

A:客户端使用受权认证向认证服务器请求访问令牌。

B：认证服务器验证客户端且判断受权认证是否有效，若是有效，分配访问令牌和更新令牌。

C:客户端使用访问令牌向资源服务器发出资源请求。

D:资源服务器验证访问令牌是否有效，若是有效，响应请求。

E:重复步骤C和D,直至访问令牌过时，若是客户端知道访问令牌过时，直接跳到步骤G,不然会继续发出资源请求。

F:因为访问令牌过时，资源服务器返回访问令牌过时错误。

G:客户端使用更新令牌向认证服务器认证，得到新的访问令牌。客户端受权需求是基于客户端类型和认证服务器的政策基础上的。

H:认证服务器认证客户端并判断更新令牌是否有效，若是有效，分配一个新的访问令牌。（可选择一个新的更新令牌）

步骤C、D、E、F不在本文档叙述范围，详情参考Section 7

1.6 运输层安全（Transport Layer Security:TLS)版本

不管TLS被这篇文档什么时候使用，基于普遍的部署和安全缺陷的考虑上，TLS相应的版本也会因时而异。写这篇文档是，TLS最新版本是1.2，可是部署受限且实现起来并不简易。TLS 1.0版本应用最为普遍且互操做性最好。

实现可能支持其余知足他们安全需求的运输船安全机制。

1.7 HTTP 重定向（HTTP Redirections)

这篇文档使用了大量的HTTP重定向，以便客户端或认证服务器导向用户到另外的目的地。虽然篇文档中的事例代表HTTP 302状态码的使用，经由用户代理可获得的方法实现重定向是被容许的且被考虑成为实现的细节。

1.8 互操做性（Interoperability）

OAuth 2.0 提供了丰富的、被很好的定义了安全性能的受权框架。然而，做为一个拥有许多可选择的组件且具备丰富和可扩展性的框架，就其自己而言，这篇文档更多的介绍了非互操做性实现。

除此以外，这篇文档还保留了一下还没有定义或定义了部分的被要求的组件（例如：客户端等级，认证服务器性能，端点发现），没有这些组件，客户端须要手动的，特定地与认证服务器和资源服务器配置，为了可以互操做。

这个框架是带有明确的指望（将来的工做将会定义规范的文档和扩展性必须实现彻底网络规模互操做性）被设计的。

1.9 符号常规（Notational Conventions）

关键词“MUST","MUST NOT","REQUIRED","SHALL","SHALL NOT","SHOULD","SHOULD NOT","RECCOMENDED","MAY",以及”OPTIONAL"在这篇文档中被解释为如RFC2119所描述。

这篇文档使用RFC5324中的扩展巴克斯范式（Augmented Bacus-Naur Form:ABNF)符号。此外，URI-reference的规则是包含在URI：generic syntax(Uniform Resource Indentifier:统一资源标识符)RFC3986

某几个与安全相关的术语是在RFC4949中被定义的意义上来理解，这些术语包括但不局限于：“attack","authentation","authorization","certificate","confidentiality","credential","encryption","identify","sign","signature","trust","validate"和"verify".

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