OAuth2

为何须要oAuth2?

假设有一个“云笔记”产品，并提供了“云笔记服务”和“云相册服务”，此时用户须要在不一样的设备（PC、Android、iPhone、TV、Watch）上去访问这些“资源”（笔记，图片）

那么用户如何才能访问属于本身的那部分资源呢？此时传统的作法就是提供本身的帐号和密码给咱们的“云笔记”，登陆成功后就能够获取资源了。但这样的作法会有如下几个问题：

• “云笔记服务”和“云相册服务”会分别部署，难道咱们要分别登陆吗？
• 若是有第三方应用程序想要接入咱们的“云笔记”，难道须要用户提供帐号和密码给第三方应用程序，让他记录后再访问咱们的资源吗？
• 用户如何限制第三方应用程序在咱们“云笔记”的受权范围和使用期限？难道把全部资料都永久暴露给它吗？
• 若是用户修改了密码收回了权限，那么全部第三方应用程序会所有失效.
• 只要有一个接入的第三方应用程序遭到破解，那么用户的密码就会泄露，后果不堪设想。

为了解决相似以上问题oAuth2应用而生

oAuth2是什么？

OAuth（开放受权）是一个开放标准，容许用户受权第三方移动应用访问他们存储在另外的服务提供者上的信息，而不须要将用户名和密码提供给第三方移动应用或分享他们数据的全部内容，OAuth2.0是OAuth协议的延续版本，但不向后兼容OAuth 1.0即彻底废止了OAuth1.0。

OAuth 2.0 的标准是 RFC 6749 文件。该文件先解释了 OAuth是引入了一个受权层，用来分离两种不一样的角色：客户端和资源全部者。......资源全部者赞成之后，资源服务器能够向客户端颁发令牌。客户端经过令牌，去请求数据。OAuth 的核心就是向第三方应用颁发令牌。

oAuth的2规则中的名词解释

• 第三方应用程序（Third-party application）： 又称之为客户端（client），好比上节中提到的设备（PC、Android、iPhone、TV、Watch），咱们会在这些设备中安装咱们本身研发的 APP。又好比咱们的产品想要使用 QQ、微信等第三方登陆。对咱们的产品来讲，QQ、微信登陆是第三方登陆系统。咱们又须要第三方登陆系统的资源（头像、昵称等）。对于 QQ、微信等系统咱们又是第三方应用程序。
• HTTP 服务提供商（HTTP service）： 咱们的云笔记产品以及 QQ、微信等均可以称之为“服务提供商”。
• 资源全部者（Resource Owner）： 又称之为用户（user）。
• 用户代理（User Agent）： 好比浏览器，代替用户去访问这些资源。
• 认证服务器（Authorization server）： 即服务提供商专门用来处理认证的服务器，简单点说就是登陆功能（验证用户的帐号密码是否正确以及分配相应的权限）
• 资源服务器（Resource server）： 即服务提供商存放用户生成的资源的服务器。它与认证服务器，能够是同一台服务器，也能够是不一样的服务器。简单点说就是资源的访问入口，好比上节中提到的“云笔记服务”和“云相册服务”均可以称之为资源服务器。

oAuth2规则的运行

（A）用户打开客户端之后，客户端要求用户给予受权。

（B）用户赞成给予客户端受权。

（C）客户端使用上一步得到的受权，向认证服务器申请令牌。

（D）认证服务器对客户端进行认证之后，确认无误，赞成发放令牌。

（E）客户端使用令牌，向资源服务器申请获取资源。

（F）资源服务器确认令牌无误，赞成向客户端开放资源。

oAuth2规则的客户端受权方式

• 受权码模式（authorization code）

  （A）用户访问客户端，后者将前者导向认证服务器。

  （B）用户选择是否给予客户端受权。

  （C）假设用户给予受权，认证服务器将用户导向客户端事先指定的"重定向URI"（redirection URI），同时附上一个受权码。

  （D）客户端收到受权码，附上早先的"重定向URI"，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见。

  （E）认证服务器核对了受权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。

• 简化模式（implicit）

  （A）客户端将用户导向认证服务器。

  （B）用户决定是否给于客户端受权。

  （C）假设用户给予受权，认证服务器将用户导向客户端指定的"重定向URI"，并在URI的Hash部分包含了访问令牌。

  （D）浏览器向资源服务器发出请求，其中不包括上一步收到的Hash值。

  （E）资源服务器返回一个网页，其中包含的代码能够获取Hash值中的令牌。

  （F）浏览器执行上一步得到的脚本，提取出令牌。

  （G）浏览器将令牌发给客户端。

• 密码模式（resource owner password credentials）

  （A）用户向客户端提供用户名和密码。

  （B）客户端将用户名和密码发给认证服务器，向后者请求令牌。

  （C）认证服务器确认无误后，向客户端提供访问令牌。

• 客户端模式（client credentials）

  （A）客户端向认证服务器进行身份认证，并要求一个访问令牌。

  （B）认证服务器确认无误后，向客户端提供访问令牌。

oAuth2客户端的受权码模式详细步骤

受权码模式（authorization code）是功能最完整、流程最严密的受权模式。它的特色就是经过客户端的后台服务器，与"服务提供商"的认证服务器进行互动。

（A） 用户访问客户端，后者将前者导向认证服务器;客户端申请认证的URI，包含如下参数：

response_type：表示受权类型，必选项，此处的值固定为"code"
client_id：表示客户端的ID，必选项
redirect_uri：表示重定向URI，可选项
scope：表示申请的权限范围，可选项
state：表示客户端的当前状态，任意字符串，认证服务器会原封不动地返回这个值，也是用来防止跨站点请求伪造攻击，必选项

eg:
    GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
    &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1

（B） 用户选择是否给予客户端受权。

（C） 假设用户给予受权，认证服务器将用户导向客户端事先指定的"重定向URI"（redirection URI），同时附上一个受权码;
服务器回应客户端的URI，包含如下参数:

code：表示受权码，必选项。该码的有效期应该很短，一般设为10分钟，客户端只能使用该码一次，不然会被受权服务器拒绝。该码与客户端ID和重定向URI，是一一对应关系。
state：若是客户端的请求中包含这个参数，认证服务器的回应也必须如出一辙包含这个参数

eg：
    Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz

（D） 客户端收到受权码，附上早先的"重定向URI"，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见;客户端向认证服务器申请令牌的HTTP请求，包含如下参数：

grant_type：表示使用的受权模式，必选项，此处的值固定为"authorization_code"。
code：表示上一步得到的受权码，必选项。
redirect_uri：表示重定向URI 应用程序中的URL，用于在受权后发送用户,必选项，且必须与A步骤中的该参数值保持一致。
client_id：表示应用程序的客户端ID，必选项
client_secrect：表示应用程序的客户机密也便是访问的资源权限，必选项

eg：
    POST /token HTTP/1.1
    Host: server.example.com
    Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
    Content-Type: application/x-www-form-urlencoded
    grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
    &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

（E） 认证服务器核对了受权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）；认证服务器发送的HTTP回复，包含如下参数：

access_token：表示访问令牌，必选项。
token_type：表示令牌类型，该值大小写不敏感，必选项，能够是bearer类型或mac类型。
expires_in：表示过时时间，单位为秒。若是省略该参数，必须其余方式设置过时时间。
refresh_token：表示更新令牌，用来获取下一次的访问令牌，可选项。
scope：表示权限范围，若是与客户端申请的范围一致，此项可省略。

eg:
    HTTP/1.1 200 OK
    Content-Type: application/json;charset=UTF-8
    Cache-Control: no-store
    Pragma: no-cache
    {
       "access_token":"2YotnFZFEjr1zCsicMWpAA",
       "token_type":"example",
       "expires_in":3600,
       "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
       "example_parameter":"example_value"
    }

流程图以下

更新令牌

令牌的有效期到了，若是让用户从新走一遍上面的流程，再申请一个新的令牌，极可能体验很差，并且也没有必要。OAuth 2.0 容许用户自动更新令牌。

具体方法是，资源服务器颁发令牌的时候，一次性颁发两个令牌，一个用于获取数据，另外一个用于获取新的令牌（refresh token 字段）。令牌到期前，用户使用 refresh token 发一个请求，去更新令牌。

https://b.com/oauth/token?
        grant_type=refresh_token&
        client_id=CLIENT_ID&
        client_secret=CLIENT_SECRET&
        refresh_token=REFRESH_TOKEN

URL中，grant_type参数为refresh_token表示要求更新令牌，client_id参数和client_secret参数用于确认身份，refresh_token参数就是用于更新令牌的令牌。资源服务器验证经过之后，就会颁发新的令牌。

oAuth2 四种方式比较

密码模式（resource owner password credentials）

• 这种模式是最不推荐的，由于client可能存了用户密码
• 这种模式主要用来作遗留项目升级为oauth2的适配方案
• 固然若是client是自家的应用，也是能够
• 支持refresh token

受权码模式（authorization code）

• 这种模式算是正宗的oauth2的受权模式
• 设计了auth code，经过这个code再获取token
• 支持refresh token

简化模式（implicit）

• 这种模式比受权码模式少了code环节，回调url直接携带token
• 这种模式的使用场景是基于浏览器的应用
• 这种模式基于安全性考虑，建议把token时效设置短一些
• 不支持refresh token

客户端模式（client credentials）

• 这种模式直接根据client的id和密钥便可获取token，无需用户参与
• 这种模式比较合适消费api的后端服务，好比拉取一组用户信息等
• 不支持refresh token，主要是没有必要

  refresh token的初衷主要是为了用户体验不想用户重复输入帐号密码来换取新token，于是设计了refresh token用于换取新token

  这种模式因为没有用户参与，并且也不须要用户帐号密码，仅仅根据本身的id和密钥就能够换取新token，于是不必refresh token

安全问题

1. redirect_uri

   问：为何 OAuth 2.0 要求申请 client_id 的时候必须输入一个域名，而且要求 redirect_uri 必须是此域名下的地址?

   答：若是别人知道了咱们的 client_id，而后在第二部生成受权链接的时候，把 redirect_uri 替换成本身与域名下的，就会能获取 code 并存放在本身服务器上

2. code

   若是 第三反方服务 不支持https，就会有被劫持的风险。若是没有 code，而是直接返回 access_token 在 redirect_uri 中，中间人就能够直接使用 access_token

3. app_secret

   若是 code 被中间人获取，在没有 app_secret 的状况下，就能够直接用 code 换取 access_token。由于在整个获取 code 的过程当中都是暴露在外的

4. state

   state 参数若是利用起来，看成 CSRF Token，就能避免此事的发生：

   1. 攻击者依旧获取 code 并打算骗受害者点击
   2. 受害者点击连接，但因服务器（好比 chrisyue.com）分配给受害者的设备的 state 值和连接里面的 state 值不同，服务器（chrisyue.com）直接返回验证 state 失败

`state` 或者说 `CSRF Token` 这种跟设备绑定的随机字符串，只要稍微复杂一点，攻击者根本就不可能猜得出来，而设置一个让攻击者猜不到的，跟设备或者说浏览器绑定的 state （CSRF token） 值，就是解决 CSRF 攻击的关键。

oAuth2实现过程小结

关于Auth2的的实现机制，就是不一样的客户端须要向资源服务器经过请求令牌（access_token）来获取不一样的资源,服务器须要去验证访问的客户端是不是在该资源服务器注册过的，以及该客户端被分配到的资源服务器的可访问的权限是什么，因此须要用户首先被客户端重定向到认证服务器来验证它的身份，验证经过，返回一个用来获取token的只能使用一次的一个code码做为请求token的参数，客户端请求token的时候还必须传递一个须要获取资源权限的必选参数client_secrect,以及参数client_id（客户端的身份),验证经过，则客户端获取到资源并展现给用户。

参考资料：
https://www.jianshu.com/p/a7d...
http://www.ruanyifeng.com/blo...
http://www.ruanyifeng.com/blo...
http://www.ruanyifeng.com/blo...
https://developer.github.com/...
https://www.jianshu.com/p/7b1...