1. 是什么？

   目前最流行的授权机制，用来授权第三方应用，获取用户数据

2. 为什么出现？

   • 用户体验优化：如果用户登录的某个应用，此时还想使用另一个应用，用户只需要授权，无需再输入账户密码即可进入第三方应用。
   • 安全：授权后，应用可知晓调用方来源

3. 授权流程是什么？

   数据的所有者（比如我的信息）告诉系统（微信），允许第三方应用（QQ）进入系统，获取这些数据。系统产生一个短期的access_token 令牌，来代替用户名密码，供第三方应用进入应用获取我的数据。

4. 令牌设计 和 密码对比

   1. 密码。相当于第三方，完全掌控了 授权人 在系统中的所有权限，第三方可任意时间进入系统，可进入授权人不想授权的访问数据范围。
   2. 令牌
      1. 授权时间的控制
         • 令牌是有时效性。一般防止令牌泄漏的风险，令牌的有效期设置的很短。
      2. 授权发放和撤销的控制
      3. 权限范围控制
         • 只读 & 读写

5. 授权方式- authorization grant

   1. 授权码模式（authorization-code）

      1. 大致流程：第三方首先申请到一个授权码，之后通过授权码换取token

      2. 特点

         1. 安全性最高
         2. 授权码通过前端传送，令牌存储在后端

      3. 适用系统：有后端的web应用

      4. 细致流程

         1. A 网站提供一个链接，用户点击后就会跳转到 B 网站，授权用户数据给 A 网站使用。下面就是 A 网站跳转 B 网站的一个示意链接。

            参数

            https://b.com/oauth/authorize?
              response_type=code&. // 表示要求返回授权码（code）
              client_id=CLIENT_ID& // 表示a的身份
              redirect_uri=CALLBACK_URL& //  B 接受或拒绝请求后的跳转网址
              scope=read  // 表示要求的授权范围（这里是只读）
            

         2. 用户跳转后，B 网站会要求用户登录，然后询问是否同意给予 A 网站授权。用户表示同意，这时 B 网站就会跳回redirect_uri参数指定的网址。跳转时，会传回一个授权码，就像下面这样

            https://a.com/callback?code=AUTHORIZATION_CODE   // code参数就是授权码
            

         3. A 网站拿到授权码以后，就可以在后端，向 B 网站请求令牌。

            https://b.com/oauth/token?
             client_id=CLIENT_ID&
             client_secret=CLIENT_SECRET&  //client_id参数和client_secret参数用来让 B 确认 A 的身份（client_secret参数是保密的，因此只能在后端发请求）
             grant_type=authorization_code&  // 表示采用的授权方式是授权码
             code=AUTHORIZATION_CODE&
             redirect_uri=CALLBACK_URL  // 参数是令牌颁发后的回调网址
            

         4. B 网站收到请求以后，就会颁发令牌。具体做法是向redirect_uri指定的网址，发送一段 JSON 数据。

            {    
              "access_token":"ACCESS_TOKEN",  // 令牌
              "token_type":"bearer",
              "expires_in":2592000,
              "refresh_token":"REFRESH_TOKEN",  // 令牌过期后，可用此token申请更新
              "scope":"read",
              "uid":100101,
              "info":{...}
            }
            

   2. 隐藏式（implicit）

      1. 适用系统：纯前端应用

      2. 特点：

         1. 无授权码中间步骤
         2. 很不安全。所以必须要求令牌的有效期必须非常短，通常就是会话期间（session）有效，

      3. 详细步骤

         1. A 网站提供一个链接，要求用户跳转到 B 网站，授权用户数据给 A 网站使用。

            https://b.com/oauth/authorize?
              response_type=token&
              client_id=CLIENT_ID&
              redirect_uri=CALLBACK_URL&
              scope=read
            

         2. 用户跳转到 B 网站，登录后同意给予 A 网站授权。这时，B 网站就会跳回redirect_uri参数指定的跳转网址，并且把令牌作为 URL 参数，传给 A 网站

            https://a.com/callback#token=ACCESS_TOKEN
            

            注意，令牌的位置是 URL 锚点（fragment）即url “#” 后面的，而不是查询字符串（querystring）即？后面的，这是因为 OAuth 2.0 允许跳转网址是 HTTP 协议，因此存在"中间人攻击"的风险，而浏览器跳转时，锚点不会发到服务器，就减少了泄漏令牌的风险

            解释：锚点 - 主要资源是由 URI 进行标识，URI 中的 fragment 用来标识次级资源。在 URI 的末尾通过 hash mark（#）作为 fragment 的开头，其中 # 不属于 fragment 的值。

   3. 密码式（password）

      1. 特点：

         1. 用户高度信任第三方应用
         2. 风险很大

      2. 流程

         1. A 网站要求用户提供 B 网站的用户名和密码。拿到以后，A 就直接向 B 请求令牌

            https://oauth.b.com/token?
              grant_type=password&  // 授权方式 密码式
              username=USERNAME&
              password=PASSWORD&
              client_id=CLIENT_ID
            

         2. B 网站验证身份通过后，直接给出令牌。注意，这时不需要跳转，而是把令牌放在 JSON 数据里面，作为 HTTP 回应，A 因此拿到令牌

   4. 客户端凭证式（client credentials）

      1. 适用：

         1. 没有前端的命令行应用
         2. 是针对第三方应用的，而不是针对用户的，即有可能多个用户共享同一个令牌。 -- 接口安全验证

      2. 一般saas系统会用到

   5. 流程

      1. A 应用在命令行向 B 发出请求。

         https://oauth.b.com/token?
           grant_type=client_credentials&  // 表示采用凭证式
           client_id=CLIENT_ID&  // B 确认 A 的身份
           client_secret=CLIENT_SECRET  // B 确认 A 的身份
         

         2. B 网站验证通过以后，直接返回令牌。

         3. 之后，A网站每次请求B网站，带着此令牌即可来表明身份。一般还会进行验签，保证安全

6. 令牌的使用

   1. A 网站拿到令牌以后，就可以向 B 网站的 API 请求数据了。

   2. 具体做法：在请求的头信息，加上一个Authorization字段

      curl -H "Authorization: Bearer ACCESS_TOKEN" \
      "https://api.b.com"
      

      上面命令中，ACCESS_TOKEN就是拿到的令牌。

7. 更新令牌

   令牌的有效期到了，如果让用户重新走一遍上面的流程，再申请一个新的令牌，很可能体验不好，而且也没有必要。OAuth 2.0 允许用户自动更新令牌。

   具体方法是，B 网站颁发令牌的时候，一次性颁发两个令牌，一个用于获取数据，另一个用于获取新的令牌（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
   

   B 网站验证通过以后，就会颁发新的令牌。

参考：

1. OAuth2.0简单介绍 ：http://www.ruanyifeng.com/blog/2019/04/oauth_design.html
2. OAuth2.0四种授权方式：http://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.html
3. 第三方登录示例：http://www.ruanyifeng.com/blog/2019/04/github-oauth.html