理解OAuth 2.0

时间 2019-11-18

标签理解 oauth 2.0 繁體版

原文原文链接

目录：
    * 名词定义
    * OAuth的思路
    * 运行流程
    * 客户端的四种受权模式

1、名词定义web

（1） Third-party application：第三方应用程序，本文中又称”客户端”（client）。
（2）Resource Owner：资源全部者，本文中又称”用户”（user）。
（3）User Agent：用户代理，指浏览器、APP等。
（4）Authorization server：认证服务器，即服务提供商专门用来处理认证的服务器。
（5）Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器。它与认证服务器，能够是同一台服务器，也能够是不一样的服务器。浏览器

2、OAuth的思路安全

OAuth在"客户端"与"服务提供商"之间，设置了一个受权层（authorization layer）。"客户端"不能直接登陆"服务提供商"，只能登陆受权层，以此将用户与客户端区分开来。"客户端"登陆受权层所用的令牌（token），与用户的密码不一样。用户能够在登陆的时候，指定受权层令牌的权限范围和有效期。服务器

"客户端"登陆受权层之后，"服务提供商"根据令牌的权限范围和有效期，向"客户端"开放用户储存的资料。app

3、运行流程框架

OAuth 2.0 的运行流程以下图，摘自RFC 6749。优化

（A）受权请求。用户打开客户端终端（web or APP）之后，客户端要求用户给予受权。这个受权请求能够直接提交给资源全部者。（如图所示），或最好是间接经过受权层做为中介进行受权。
（B）用户受权。客户端收到了一个来自用户的受权凭证。这个凭证，能够经过四种方式来获取，至于哪四种，下面有介绍。
（C）请求认证服务器受权。客户端使用上面用户受权获得的凭证向认证服务器请求一个拥有特定访问权限的访问令牌（access token），注意，access token 是和权限绑定的。
（D）发放令牌。认证服务器向客户端发放客户端在上一步请求的令牌。
（E）请求资源。客户端使用访问令牌向资源服务器请求用户的受保护的资源。
（F）返回资源。资源服务器验证访问令牌是否有效，有效则返回请求的资源。如何判断是否有效呢，固然是调用认证服务器的准备好的服务了。

上面六个步骤之中，B是关键，即用户怎样才能给于客户端受权。有了这个受权之后，客户端就能够获取令牌，进而凭令牌获取资源。操作系统

4、客户端的四种受权模式代理

客户端必须获得用户的受权（authorization grant），才能得到令牌（access token）。OAuth 2.0 定义了四种受权模式。code

* 受权码模式（authorization code）
* 简化模式（implicit）
* 密码模式（resource owner password credentials）
* 客户端模式（client credentials）

1. 受权码模式

它的特色就是经过客户端的后台服务器，与”服务提供商”的认证服务器进行互动。受权码受权方式用于同时获取 accessToken 和 refreshToken，并对信任的客户端进行了优化。因为这是一个基于重定向的流程，client 必须能与 resource owner 的 user-agent（一般是浏览器）进行交互而且可以接收到 authorization server 经过重定向传入的请求。

（A）客户端将用户浏览器引导向认证端。客户端包含了客户端标识 client_id，请求受权范围 scope，本地状态state，回调地址 redirect_uri，一旦被受权（或被拒绝），认证服务器将会把回调地址返回给浏览器。
（B）用户操做受权，好比用户进行选择资源范围，输入密码点肯定发送请求，决定是否给客户端受权。
（C）认证服务器校验用户真实性，假设用户给予受权，认证服务器将用户导向客户端事先指定的回调地址 redirect_uri，回调地址后面同时附上一个受权码 code 和以前设置的 state （这里的state，其实就是客户端预留的，用以当受权成功后，执行某些事件等，好比能够放一个js的方法名）。
（D）客户端使用上一步返回的受权码 code 附上以前用来获取受权码的回调地址 redirect_uri 向认证服务器请求一个访问令牌 （access token）。这一步是在客户端的后台的服务器上完成的，对用户不可见。
（E）认证服务器核对了受权码和重定向URI，和在（C）步骤中的两个参数比对确认无误后，向客户端发送访问令牌（access token）和可选的刷新令牌（refresh token）。

在这个流程里面，有几个关键的参数，client_id，redirect_uri，code，access token，refresh token，下面简单解释一下。

client_id：客户端id。这个是认证端预先分配给客户端的。好比说，你要使用QQ登陆新浪，那么新浪确定是须要在QQ的认证中心备案的，而后 QQ 给新浪一个client_id，可能还有个secret，而后在约定一个回调地址 redirect_uri。而后新浪才能调用 QQ 的受权页面展现给用户看，让用户受权。

redirect_uri：回调地址。当你在QQ页面上受权完了，就会跳转到这个URI，就是受权成功后执行一些什么操做。若是没有这玩意的话，当你受权完了，而后呢，新浪也不知道接下来应该干吗。

code：为何要使用code呢？由于安全，这样，user agent 端只会出现code，正常状况下不会存在access token 和 refresh token，access token 和 refresh token只会在客户端即第三方的服务端和资源所在的服务器端流通。每每，客户端（user agent）被认为是不安全的，因此要尽可能把重要的信息存在服务器端，以防止被篡改使用。

access token：即访问令牌。访问令牌用来访问资源信息，它自己就是权限，用户不可见。访问令牌的出现，可让用户自主设定一个权限范围，也有了随时取消第三方权限的方式。它还有时效性，一般在返回该令牌的时候，也会随之返回一个有效时间，几十分钟到几十天不等，看认证服务器端的设置。OAuth 1.0 的时候，accessToken 是没有时间限制的，就是永久有效，这样的话，那第三方就能一直使用该令牌获取用户的资源，那若是用户好几个月都没有登陆认证服务器设置，或者是忘记了，那么第三方就能永远能够访问，不太好，因此，在OAuth 2.0 的时候，增长了 refresh token。

refresh token：用途，看字面意思就知道，刷新令牌，当 access token 过时以后刷新出新的 access token。那就与上面的说法又矛盾了，这样一来的话，那不就是说能够一直使用 refresh token 来刷新出有效的 access token，这不就是变相的能够永久访问吗？确实，这是一个问题，因此，通常， refresh token 也是有时效性的，有过时时间，甚至，好多公司直接去掉了 refresh token ，仅仅返回有必定时间限制的 access token。那 refresh token 的存在乎义又在哪里呢，应该是：有了它，能够改变 access token 的属性而不用再次经历受权。好比更改 accessToken 的权限的时候，只要使用 refresh token来刷新一个新的就行了，而不用再输入密码什么的。

2. 简化模式

简化模式（implicit grant type）不经过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了"受权码"这个步骤，所以得名。全部步骤在浏览器中完成，令牌对访问者是可见的，且客户端不须要认证。

（A）客户端将用户导向认证服务器。
（B）用户决定是否给于客户端受权。
（C）假设用户给予受权，认证服务器将用户导向客户端指定的"重定向URI"，并在URI的Hash部分包含了访问令牌。
（D）浏览器向资源服务器发出请求，其中不包括上一步收到的Hash值。
（E）资源服务器返回一个网页，其中包含的代码能够获取Hash值中的令牌。
（F）浏览器执行上一步得到的脚本，提取出令牌。
（G）浏览器将令牌发给客户端。

3.密码模式

密码模式（Resource Owner Password Credentials Grant）中，用户向客户端提供本身的用户名和密码。客户端使用这些信息，向"服务商提供商"索要受权。

在这种模式中，用户必须把本身的密码给客户端，可是客户端不得储存密码。这一般用在用户对客户端高度信任的状况下，好比客户端是操做系统的一部分，或者由一个著名公司出品。而认证服务器只有在其余受权模式没法执行的状况下，才能考虑使用这种模式。

（A）用户向客户端提供用户名和密码。
（B）客户端将用户名和密码发给认证服务器，向后者请求令牌。
（C）认证服务器确认无误后，向客户端提供访问令牌。

4.客户端模式

客户端模式（Client Credentials Grant）指客户端以本身的名义，而不是以用户的名义，向"服务提供商"进行认证。严格地说，客户端模式并不属于OAuth框架所要解决的问题。在这种模式中，用户直接向客户端注册，客户端以本身的名义要求"服务提供商"提供服务，其实不存在受权问题。

（A）客户端向认证服务器进行身份认证，并要求一个访问令牌。
（B）认证服务器确认无误后，向客户端提供访问令牌。