OAuth2是RFC6749中所定义用于分布式系统接近第三方认证授权的协议，主要用于解决第三方不可信的问题(防止第三方存取账号密码造成的不安全问题)。简单来说就是我们开发的应用不用去接触淘宝、QQ他们的密码，但是也能利用他们的账号体系完成认证工作。

四种模式

授权码模式（重要）

几乎避免了所有的敏感信息泄露

过程描述，以淘宝登录为例：

文字描述

1. 开发者注册应用

   1. 应用开发者（第三方应用）到淘宝认证服务器（认证服务器）注册，并填写授权回调域，此步目的是获取appID和appSecret

2. 获取code

   1. 用户在前端选择微信登录，并向后端发送请求
   2. 后端收到前端请求后，拿着appid，secret，回调地址等信息，向淘宝认证服务器发送请求，授权服务器根据appid、secret确认应用身份，成功后会返回一个code
   3. 后端将得到的code返回给前端

3. 获取令牌（用code换access_token）

   1. 前端访问微信的展示登录二维码（或跳转认证提供方的登录页码）
   2. 用户带着上一步获取的code完成在认证提供方的认证
   3. 并在微信的登录页面（一般是由授权提供方提供），进行扫码（或输入账号密码），发起请求
   4. 淘宝服务器接收到请求，并回调第二步中的回调地址
   5. 后端收到回调，获取到token令牌，此时认证完成

4. 前端轮询状态

   1. 前端带着前面的code继续请求后端，询问是否认证成功，如果认证成功，后端返回token

专有名词解释：

1. 授权回调域：在授权回调域内的地址，才可进行Oauth2认证，非规范内规定的内容，微信有，其他的不一定有。顺便吐槽一下微信，我理解的回调是认证服务器去请求我们后端这叫做回调，这里明显是用授权认证域更合适。
2. 回调地址：由认证平台向我们后端发送认证的消息的地址

说明：

几个网站的授权流图

隐式授权模式

省略了code换取令牌的部分，用户拿到code之后可以直接去换取令牌 ，令牌将直接返回给客户端，所以在这个模式下应保证客户端是可信的

密码模式

直接向授权服务器发送用户的账号密码，简言之就是用户将自己在微信/QQ的账户密码告诉我们，让我们去代替他登录，所以这样我们的应用、授权服务器、用户三方必须都保持互信。虽然在OAuth2上说明了，第三方应用（我们开发的应用）不得保持用户的密码，但是这显然没有任何技术性约束力。

客户端模式（微服务常用）

应用以自己的名义访问授权服务器，并获得许可，这种模式在微服务中应该是经常遇到的。