参考：参考网站
- 授权码模式（适用于前后端分离）
这种方式是最常用的流程，安全性也最高，它适用于那些有后端的 Web 应用。授权码通过前端传送，令牌则是储存在后端，而且所有与资源服务器的通信都在后端完成。这样的前后端分离，可以避免令牌泄漏。
一般应用于第三方网站通过微信、QQ、Github登陆就是这种模式
网站应用微信登陆开发指南
问题：为什么使用授权码
原因：避免令牌泄露
问题：为什么不直接返回授权码给B站
原因：多个授权码同时返回给B站，B站无法判断哪个授权码属于哪个用户
- 隐藏式（适合没有后台的第三方，不推荐）
有些 Web 应用是纯前端应用，没有后端。这时就不能用上面的方式了，必须将令牌储存在前端。RFC 6749 就规定了第二种方式，允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤，所以称为（授权码）“隐藏式”（implicit）。
第一步，B站提供一个链接，要求用户跳转到微信，授权用户数据给B站使用。
https://b.com/oauth/authorize?
response_type=token&
client_id=CLIENT_ID&
redirect_uri=CALLBACK_URL&
scope=read
第二步，用户跳转到微信登陆网站，登录后同意给予B站授权。之后，微信跳回redirect_uri参数指定的跳转网址，并且把令牌作为 URL 参数，传给 B站。
第三步，B站拿着令牌去微信获得用户资源
注意：这种方式把令牌直接传给前端，是很不安全的。因此，只能用于一些安全要求不高的场景，并且令牌的有效期必须非常短，通常就是会话期间（session）有效，浏览器关掉，令牌就失效了。
- 密码式（用户极其信任第三方）
如果你高度信任某个应用，RFC 6749 也允许用户把用户名和密码，直接告诉该应用。该应用就使用你的密码，申请令牌，这种方式称为"密码式"（password）
使用总结：Laravel 的 passport 密码授权模式完成 API 认证
从文章看来，其实密码模式可以用于前后端完全分离的情况下。这时的前端（或者仅仅是个postman）类似于第三方服务器（B站），通过API向后端（授权服务端）（微信）请求资源。
还可以用于同一个公司的不同产品下。例如微博和新浪邮箱，只要一个登陆另一个就不用登陆了。
第一步，B站要求用户提供 微信的用户名和密码。拿到以后，B站 就直接向 微信 请求令牌
（postman输入用户的账号密码，然后直接向API请求令牌）
https://oauth.b.com/token?
grant_type=password&
username=USERNAME&
password=PASSWORD&
client_id=CLIENT_ID
第二步，微信验证身份通过后，直接给出令牌。注意，这时不需要跳转，而是把令牌放在 JSON 数据里面，作为 HTTP 回应，B站 因此拿到令牌。
（验证通过后，API将令牌返回给postman）
第三步，B站拿着令牌去微信获得用户资源
- 凭证式（客户端模式，适合没有前端的第三方，整个过程没有用户参与）
最后一种方式是凭证式（client credentials），适用于没有前端的命令行应用，即在命令行下请求令牌
第一步，B站 应用在命令行向 微信 发出请求。
https://oauth.b.com/token?
grant_type=client_credentials&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET
第二步，微信 网站验证通过以后，直接返回令牌。
第三步，B站拿着令牌去微信获得所需要的资源
这种方式给出的令牌，是针对第三方应用的，而不是针对用户的，即有可能多个用户共享同一个令牌。
