一、OAuth2认证
OAuth2是一个关于授权的开放标准，核心思路是通过各类认证手段（具体什么手段OAuth2不关心）认证用户身份，并颁发token（令牌），
使得第三方应用可以使用该token（令牌）在限定时间、限定范围访问指定资源。
OAuth2相关概念：
资源所有者（resources owner）：拥有被访问资源的用户
客户端/第三方应用（client）：第三方应用，获取资源服务器提供的资源
授权服务器（authorization server）：认证服务器，提供授权许可code、令牌token等
资源服务器（resource server）：资源服务器，拥有被访问资源的服务器，需要通过token来确定是否有权限访问
OAuth2几种模式：
获取令牌的方式主要有四种，分别是授权码模式、隐式授权码模式（简单模式）、密码模式和客户端模式。
1）授权码模式（authorization code）
这种模式是最安全的OAuth2的授权模式。设计了auth code，通过这个code再获取token，最后通过token获取资源。支持refresh token。
应用场景：
各大应用内的qq，微信，微博登录等。比如某应用内的qq登录，过程如下：
a.用户点击qq登录，会先跳转到qq登录页面，这时请求已经跳转到qq服务器了，然后用户输入账号或者扫码登录，这时所有请求都在qq服务器完成。
b.用户正确登录后，qq服务器返回用户的code给第三方应用，然后第三方应用再使用code去授权服务器请求获取token。（这一步用户不可见）
c.第三方应用获取到token后，再使用token获取用户的qq名称，头像等信息。
优缺点：
优点：用户可以控制自身的一些权限是否给第三方，第三方只能获取到用户临时产生的一个访问的code，安全性。
缺点：认证过程繁琐。
2）隐式授权码模式/简单模式（implicit）
和授权码模式类似，只不过少了获取code的步骤，是直接获取令牌token的，适用于公开的浏览器单页应用，令牌直接从授权服务器返回，不支持刷新令牌，且没有code安全保证，令牌容易因为被拦截窃听而泄露。
不支持refresh token
3）密码模式（resource owner password credentials）
这种模式是最不推荐的，因为client可能存了用户密码
这种模式主要用来做遗留项目升级为oauth2的适配方案
当然如果client是自家的应用，也是可以
支持refresh token
4）客户端模式（client credentials）
这种模式直接根据client的id和密钥即可获取token，无需用户参与
这种模式比较合适消费api的后端服务，比如拉取一组用户信息等
不支持refresh token，主要是没有必要