OAuth 2.0 是目前比较流行的 应用授权机制（框架），它用于对第三方应用对授权，客户端向授权服务请求授权（通常需要携带必要的信息），授权之后返回一个 token （令牌）作为凭证，之后每次请求都携带这个 token 进行访问；

OAuth 2.0 基于 RFC6749 标准，OAuth 引入了 授权层，有两种角色：资源所有者和客户端，客户端向资源服务器申请授权，资源所有者同意后，资源服务器向客户端返回令牌，客户端携带令牌来请求资源服务器的数据

token（令牌）一般来说作用时间是短期的（一定程度上防止盗用），而且有一定的适用范围（scope），OAuth 2.0 为我们提供了四种授权的类型，供开发者选择：

  1. client credentials 客户端凭证模式
  2. password 密码模式
  3. authorization-code 授权码模式
  4. implicit 隐藏模式

任何一种模式，都需要客户端向服务器进行备案（管理员将客户端的信息写入系统），拿到客户端ID(client id) 和 客户端密钥(client secret)，才能向资源服务器申请授权；

授权码模式 authorization-code

授权码（authorization code）方式，指的是第三方应用先申请一个授权码，然后再用该码获取令牌

这种方式是最常用的流程，安全性也最高，它适用于那些 有后端的 Web 应用。授权码通过前端传送，令牌则是储存在后端，而且所有与资源服务器的通信都在后端完成。这样的前后端分离，可以避免令牌泄漏。

  1. A 网站提供一个链接，用户点击后就会跳转到 B 网站，授权用户数据给 A 网站使用。下面就是 A 网站跳转 B 网站的一个示意链接
    1. https://b.com/oauth/authorize?
    2. response_type=code&
    3. client_id=CLIENT_ID&
    4. redirect_uri=CALLBACK_URL&
    5. scope=read


上面 URL 中，response_type参数表示要求返回授权码（code），client_id参数让 B 知道是谁在请求，redirect_uri参数是 B 接受或拒绝请求后的跳转网址，scope参数表示要求的授权范围（这里是只读）

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


上面 URL 中，code 参数就是授权码。

  1. A 网站拿到授权码以后，就可以在后端，向 B 网站请求令牌。
    1. https://b.com/oauth/token?
    2. client_id=CLIENT_ID&
    3. client_secret=CLIENT_SECRET&
    4. grant_type=authorization_code&
    5. code=AUTHORIZATION_CODE&
    6. redirect_uri=CALLBACK_URL


上面 URL 中，client_id参数和client_secret参数用来让 B 确认 A 的身份（client_secret参数是保密的，因此只能在后端发请求），grant_type参数的值是AUTHORIZATION_CODE，表示采用的授权方式是授权码，code参数是上一步拿到的授权码，redirect_uri参数是令牌颁发后的回调网址。

  1. B 网站收到请求以后，就会颁发令牌。具体做法是向redirect_uri指定的网址，发送一段 JSON 数据。
    1. {    
    2. "access_token":"ACCESS_TOKEN",
    3. "token_type":"bearer",
    4. "expires_in":2592000,
    5. "refresh_token":"REFRESH_TOKEN",
    6. "scope":"read",
    7. "uid":100101,
    8. "info":{...}
    9. }


上面 JSON 数据中，access_token字段就是令牌，A 网站在后端拿到了。

该模式通常用于应用向第三方的应用获取数据，例如：qq、微信、微博的第三方登陆和数据获取，是 OAuth 比较常用的一个场景。

密码模式 password

如果你 高度信任 某个应用 ，OAuth 允许你将用户名、密码直接告诉该应用。该应用就使用你的密码，申请令牌，这种方式称为”密码式”（password）。

通常，该模式用于应用本身 直接对用户 提供的服务，例如某某网站的账号密码登陆（需要提供资源的应用本身有一套完善的用户体系），而不是作为第三方服务授权给其他应用。

调用步骤：

  1. A 网站要求用户提供 B 网站的用户名和密码。拿到以后，A 就直接向 B 请求令牌：
    1. https://oauth.b.com/token?
    2. grant_type=password&
    3. username=USERNAME&
    4. password=PASSWORD&
    5. client_id=CLIENT_ID


上面 URL 中，grant_type参数是授权方式，这里的password表示”密码式”，username和password是 B 的用户名和密码。

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

客户端凭证模式 client credentials

适用于没有前端的命令行应用，即在命令行下请求令牌。

  1. A 应用在命令行向 B 发出请求
    1. https://oauth.b.com/token?
    2. grant_type=client_credentials&
    3. client_id=CLIENT_ID&
    4. client_secret=CLIENT_SECRET


上面 URL 中，grant_type 参数等于 client_credentials 表示采用凭证式，client_id 和client_secret 用来让 B 确认 A 的身份。

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

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

隐藏模式 implicit

有些 Web 应用是纯前端应用，没有后端。这时就不能用上面的方式了，必须将令牌储存在前端。RFC 6749 就规定了第二种方式，允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤，所以称为（授权码）”隐藏式”（implicit）。

  1. A 网站提供一个链接，要求用户跳转到 B 网站，授权用户数据给 A 网站使用
  2. 用户跳转到 B 网站，登录后同意给予 A 网站授权。这时，B 网站就会跳回redirect_uri参数指定的跳转网址，并且把令牌作为 URL 参数，传给 A 网站

总结四种模式：

  1. 授权码模式：最安全、适用于 有后端的 Web应用 向第三方应用进行数据获取 或者 作为第三方应用向其他应用服务，提供数据；
  2. 密码模式：适合用于绝对信任的应用，通常是应用本身直接向用户提供服务（例如某某网站的账号密码登陆），需要应用有一套用户体系，而不是作为第三方服务授权给其他应用；
  3. 客户端凭证模式：适用于没有前端的命令行应用，即在命令行下请求令牌
  4. 隐藏模式：适用于Web应用是纯前端的应用（如提供api服务供前端调用，而前端只有api的调用，没有对应的后端服务）

以上部分摘抄自阮一峰博客：http://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.html，以及个人的理解，记录便于查阅，希望对你有帮助