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".
除非另有说明，所有的协议参数名称和值都是区分大小写的。