微服务统一认证方案
1、微服务架构下统一认证思路
基于Session的认证方式：
在分布式的环境下，基于session的认证会出现一个问题，每个应用服务都需要在session中存储用户身份信息，通过负载均衡将本地的请求分配到另一个应用服务需要将session信息带过去，否则会重新认证。我们可以使用Session共享、Session黏贴等方案。
Session方案也有缺点，比如基于cookie，移动端不能有效使用等。
基于token的认证方式
基于token的认证方式，服务端不用存储认证数据，易维护扩展性强， 客户端可以把token 存在任意地方，并且可以实现web和app统一认证机制。其缺点也很明显，token由于自包含信息，因此一般数据量较大，而且每次请求都需要传递，因此比较占带宽。另外，token的签名验签操作也会给cpu带来额外的处理负担。
2、OAuth2开放授权协议/标准
2.1、OAuth2介绍
OAuth（开放授权）是一个开放协议/标准，允许用户授权第三方应用访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方应用或分享他们数据的所有内容。
允许用户授权第三方应用访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方应用或分享他们数据的所有内容。
结合“使用QQ登录拉勾”这个场景拆分理解上述那句话：
- 用户：我们自己
- 第三方应用：拉勾网
- 另外的服务提供者：QQ
- OAuth2是OAuth协议的延续版本，但不向后兼容OAuth1即完全废止了OAuth1。
2.2、OAuth2协议角色和流程
拉勾网要开发使用QQ登录这个功能的话，那么拉勾网是需要提前到QQ平台进行登记的（否则QQ凭什么陪着拉勾网玩授权登录这件事）。
- 拉勾网——登记——>QQ平台
- QQ 平台会颁发一些参数给拉勾网，后续上线进行授权登录的时候（刚才打开授权页⾯）需要携带这些参数：
- client_id ：客户端id（QQ最终相当于一个认证授权服务器，拉勾网就相当于一个客户端了，所以会给一个客户端id），相当于账号
- secret：相当于密码
- 资源所有者（Resource Owner）：可以理解为用户自己
- 客户端（Client）：我们想登陆的网站或应用，比如拉勾网
- 认证服务器（Authorization Server）：可以理解为微信或者QQ
- 资源服务器（Resource Server）：可以理解为微信或者QQ
2.3、什么情况下需要使用OAuth2？
第三方授权登录的场景：比如，我们经常登录一些站或者应用的时候，可以选择使用第三方授权登录的方式，比如：微信授权登录、QQ授权登录、微博授权登录等，这是典型的 OAuth2 使用场景。
单点登录的场景：如果项目中有很多微服务或者公司内部有很多服务，可以专门做一个认证中心（充当认证平台角色），所有的服务都要到这个认证中心做认证，只做一次登录，就可以在多个授权范围内的服务中自由串行。
2.4、OAuth2的颁发Token授权方式
- 授权码（authorization-code）
- 密码式（password）提供⽤户名+密码换取token令牌
- 隐藏式（implicit）
- 客户端凭证（client credentials）
授权码模式使用到了回调地址，是最复杂的授权方式，微博、微信、QQ等第三方登录就是这种模式。我们重点讲解接口对接中常使用的password密码模式（提供用户名+密码换取token）。