什么是 OAuth2
OAuth 就是一种授权机制。数据的所有者告诉系统，同意授权第三方应用进入系统，获取这些数据。系统从而产生一个短期的进入令牌（token），用来代替密码，供第三方应用使用。
OAuth 是一个开放标准，该标准允许用户让第三方应用访问该用户在某一网站上存储的私密资源（如头像、照片、视频等），而在这个过程中无需将用户名和密码提供给第三方应用。实现这一功能是通过提供一个令牌（token），而不是用户名和密码来访问他们存放在特定服务提供者的数据。采用令牌（token）的方式可以让用户灵活的对第三方应用授权或者收回权限。
OAuth2 是 OAuth 协议的下一版本，但不向下兼容 OAuth 1.0。传统的 Web 开发登录认证一般都是基于 session 的，但是在前后端分离的架构中继续使用 session 就会有许多不便，因为移动端（Android、iOS、微信小程序等）要么不支持 cookie（微信小程序），要么使用非常不便，对于这些问题，使用 OAuth2 认证都能解决。
对于大家而言，我们在互联网应用中最常见的 OAuth2 应该就是各种第三方登录了，例如 QQ 授权登录、微信授权登录、微博授权登录、GitHub 授权登录等等。
令牌与密码
令牌（token）与密码（password）的作用是一样的，都可以进入系统，但是有三点差异。
- 令牌是短期的，到期会自动失效，用户自己无法修改。密码一般长期有效，用户不修改，就不会发生变化。
- 令牌可以被数据所有者撤销，会立即失效。以上例而言，屋主可以随时取消快递员的令牌。密码一般不允许被他人撤销。
- 令牌有权限范围（scope），比如只能进小区的二号门。对于网络服务来说，只读令牌就比读写令牌更安全。密码一般是完整权限。
上面这些设计，保证了令牌既可以让第三方应用获得权限，同时又随时可控，不会危及系统安全。这就是 OAuth2.0 的优点。
注意，只要知道了令牌，就能进入系统。系统一般不会再次确认身份，所以令牌必须保密，泄漏令牌与泄漏密码的后果是一样的。这也是为什么令牌的有效期，一般都设置得很短的原因。
授权类型
OAuth2.0 对于如何颁发令牌的细节，规定得非常详细。具体来说，一共分成四种授权类型（authorization grant），即四种颁发令牌的方式，适用于不同的互联网场景。
授权码模式
授权码模式是最安全并且使用最广泛的一种模式。
在授权码模式中，我们分授权服务器和资源服务器，授权服务器用来派发 Token，拿着 Token 则可以去资源服务器获取资源，这两个服务器可以分开，也可以合并。
流程图
上面这张流程图的含义
- 首先，第三方网站上会放一个超链接，用户 A （服务方的用户，例如微信用户）点击这个超链接就会去请求授权服务器（微信的授权服务器），用户点击的过程其实也就是第三方应用跟用户要授权的过程，这就是上图中的 1、2 步。
- 接下来的第三步，就是用户点击了超链接之后，像授权服务器发送请求，一般来说，第三方应用网页上的超链接可能有如下参数：
https://wx.qq.com/oauth/authorize?response_type=code&client_id=chenfu_app&redirect_uri=www.chenfu.top&scope=all
这里有如下参数：
- response_type 表示授权类型，使用授权码模式的时候这里固定为 code，表示要求返回授权码（将来拿着这个授权码去获取 access_token）。
- client_id 表示客户端 id，也就是我应用的 id。授权服务器在校验的时候，会做两件事：1.校验客户端的身份；2.校验用户身份。
- redirect_uri 表示用户登录在成功/失败后，跳转的地址，跳转的时候，还会携带上一个授权码参数。
- scope 表示授权范围，即第三方网站拿着用户的 token 都能干啥（一般来说就是获取用户非敏感的基本信息）。
- 第三方网站，拿着第三步获取到的 code 以及自己的 client_id 和 client_secret 以及其他一些信息去授权服务器请求令牌，微信的授权服务器在校验过这些数据之后，就会发送一个令牌回来。这个过程一般是在后端完成的，而不是利用 js 去完成。
- 接下来拿着这个 token，我们就可以去请求用户信息了。
一般情况下我们认为授权码模式是四种模式中最安全的一种模式，因为这种模式我们的 access_token 不用经过浏览器或者移动端 App，是直接从我们的后台发送到授权服务器上，这样就很大程度减少了 access_token 泄漏的风险。
简化模式
流程
在第三方网站上有一个微信登录的超链接，这个超链接类似下面（后面给出）。用户点击我这个超链接之后，就会跳转到微信登录页面，然后用户进行登录。
用户登录成功后，微信会自动重定向到 redirect_uri 参数指定的跳转网址，同时携带上 access_token，这样用户在前端就获取到 access_token 了。
https://wx.qq.com/oauth/authorize?response_type=token&client_id=chenfu_app&redirect_uri=www.chenfu.top&scope=all
这里有三个参数，含义如下：
这里的参数和前面授权码模式的基本相同，只有 response_type 的值不一样，这里是 token，表示要求授权服务器直接返回 access_token。
- response_type：值为 token，表示要求授权服务器直接返回 access_token。
- clientId： 表示客户端 id，也就是我应用的 id。
- redirect_uri：认证服务器认证成功后，重定向的跳转地址，同时携带上 access_token，这样用户在前端就获取到 access_token 了。
- scope：表示授权范围，即第三方应用这个网站拿着用户的 token 都能干啥（一般来说就是获取用户非敏感的基本信息）。
简化模式的弊端很明显，因为没有后端，所以非常不安全，除非你对安全性要求不高，否则不建议使用。
密码模式
密码模式有一个前提就是你高度信任第三方应用！
密码模式在 Spring Cloud 项目中有着非常广泛的应用，微服务中有一个特殊的场景，就是服务之间的调用，用密码模式做鉴权是非常恰当不过的了。
密码式的流程比较简单：
- 第三方应用发送一个 post 请求，类似下面这样的：
https://wx.qq.com/oauth/authorize?response_type=password&client_id=chenfu_app&username=chenfu&password=123
这里有三个参数，含义如下：（没有重定向的 redirect_uri ，因为这里不需要重定向）
- response_type：这里是 password，表示密码式
- username：用户名
- password：密码
- 微信校验过用户名/密码之后，直接在 HTTP 响应中把 access_token 返回给客户端
客户端模式
这个步骤也很简单，就两步：
- 客户端发送一个请求到授权服务器，请求格式如下：
GET https://api.weixin.qq.com/cgi-bin/token?grant_type=client_credential&client_id=APPID&client_secret=APPSECRET
这里有三个参数，含义如下：
- grant_type，获取 access_token 填写 client_credential
- client_id：应用ID，用来确认客户端的身份
- client_secret：应用秘钥，用来确认客户端的身份
- 授权服务器通过验证后，会直接返回 access_token 给客户端。