http://www.ruanyifeng.com/blog/2019/04/oauth_design.html
http://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.html

流程介绍

令牌（token）和密码（password）

令牌（token）与密码（password）的作用是一样的，都可以进入系统，但是有三点差异。
（1）令牌是短期的，到期会自动失效，用户自己无法修改。
密码一般长期有效，用户不修改，就不会发生变化。
（2）令牌可以被数据所有者撤销，会立即失效。以上例而言，屋主可以随时取消快递员的令牌。
密码一般不允许被他人撤销。
（3）令牌有权限范围（scope），比如只能进小区的二号门。对于网络服务来说，只读令牌就比读写令牌更安全。
密码一般是完整权限。

上面这些设计，保证了令牌既可以让第三方应用获得权限，同时又随时可控，不会危及系统安全。这就是 OAuth 2.0 的优点。

注意，只要知道了令牌，就能进入系统。系统一般不会再次确认身份，所以令牌必须保密，泄漏令牌与泄漏密码的后果是一样的。 这也是为什么令牌的有效期，一般都设置得很短的原因。

=====================

授权方式

也就是说，OAuth 2.0 规定了四种获得令牌的流程。你可以选择最适合自己的那一种，向第三方应用颁发令牌。下面就是这四种授权方式。

注意，不管哪一种授权方式，第三方应用申请令牌之前，都必须先到系统备案，说明自己的身份。
然后会拿到两个身份识别码：客户端 ID（client ID）和客户端密钥（client secret）。
这是为了防止令牌被滥用，没有备案过的第三方应用，是不会拿到令牌的。

1、授权码（authorization-code）

【定义】：指的是第三方应用先申请一个授权码，然后再用该码获取令牌。

【应用】：这种方式是最常用的流程，安全性也最高，它适用于那些有后端的 Web 应用。

授权码通过前端传送，令牌则是储存在后端，而且所有与资源服务器的通信都在后端完成。这样的前后端分离，可以避免令牌泄漏。

2、隐藏式（implicit）

【定义】：没有授权码

【应用】：纯前端应用，没有后端，只能将令牌储存在前端

这种方式把令牌直接传给前端，是很不安全的。因此，只能用于一些安全要求不高的场景，并且令牌的有效期必须非常短，通常就是会话期间（session）有效，浏览器关掉，令牌就失效了。

3、密码式（password）

【定义】：如果你高度信任某个应用，RFC 6749 也允许用户把用户名和密码，直接告诉该应用。该应用就使用你的密码，申请令牌。

【应用】：这种方式需要用户给出自己的用户名/密码，显然风险很大，因此只适用于其他授权方式都无法采用的情况，而且必须是用户高度信任的应用。

  1. https://oauth.b.com/token?
  2.   grant_type=password&
  3.   username=USERNAME&
  4.   password=PASSWORD&
  5.   client_id=CLIENT_ID

4、客户端凭证（client credentials）

【定义】：适用于没有前端的命令行应用，即在命令行下请求令牌

【应用】：这种方式给出的令牌，是针对第三方应用的，而不是针对用户的，即有可能多个用户共享同一个令牌。

=======================

令牌 token

使用

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

此时，每个发到 API 的请求，都必须带有令牌。

具体做法是在请求的头信息，加上一个Authorization字段，令牌就放在这个字段里面。

  1. Authorization: Bearer ACCESS_TOKEN

更新

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

OAuth 2.0 允许用户自动更新令牌。

具体方法是，B 网站颁发令牌的时候，一次性颁发两个令牌，一个用于获取数据，另一个用于获取新的令牌（refresh token 字段）。

令牌到期前，用户使用 refresh token 发一个请求，去更新令牌。

===================

第三方登录示例

http://www.ruanyifeng.com/blog/2019/04/github-oauth.html