微服务统一认证方案

统一认证思路

基于Session的认证方式

在分布式的环境下，基于session的认证会出现一个问题，每个应用服务都需要 在session中存储用户身份信息，通过负载均衡将本地的请求分配到另一个应用服务需要将session信息带过去，否则会重新认证。我们可以使用Session共享、 Session黏贴等⽅案。
Session方案也有缺点，比如基于cookie，移动端不能有效使用等

基于token的认证方式

基于token的认证方式，服务端不用存储认证数据，易维护扩展性强， 客户端可以把token 存在任意地方，并且可以实现web和app统一认证机制。
其缺点也很明显，token由于自包含信息，因此一般数据量较大，而且每次请求 都需要传递，因此比较占带宽。另外，token的签名验签操作也会给cpu带来额外的处理负担。

OAuth2开放授权协议/标准

允许用户授权第三方应用访问他们存储 在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方应用或分享他们数据的所有内容。

OAuth2协议角色和流程

(通过登录的qq访问 拉勾网)
1）拉勾网——登记——>QQ平台
2）QQ 平台会颁发一些参数给拉勾网，后续上线进行授权登录的时候（刚才打开授 权页面）需要携带这些参数 client_id ：客户端id（QQ最终相当于一个认证授权服务器，拉勾网就相当于一个客 户端了，所以会给一个客户端id），相当于账号 secret：相当于密码

资源所有者（Resource Owner）：可以理解为用户自己
客户端（Client）：我们想登陆的网站或应用，比如拉勾网
认证服务器（Authorization Server）：可以理解为微信或者QQ
资源服务器（Resource Server）：可以理解为微信或者QQ

需要使用OAuth2场景

第三方授权登录的场景：

比如，我们经常登录一些网站或者应用的时候，可以选择 使用第三方授权登录的方式，比如：微信授权登录、QQ授权登录、微博授权登录等，这是典型的 OAuth2 使用场景。

单点登录的场景：

如果项⽬中有很多微服务或者公司内部有很多服务，可以专门做一个认证中心（充当认证平台角色），所有的服务都要到这个认证中心做认证，只做一次登录，就可以在多个授权范围内的服务中自由串行。

OAuth2的颁发Token授权方式

1）授权码（authorization-code）
2）密码式（password）提供用户名+密码换取token令牌
3）隐藏式（implicit）
4）客户端凭证（client credentials）

授权码模式使用到了回调地址，是最复杂的授权方式，微博、微信、QQ等第三方登 录就是这种模式。我们重点讲解接口对接中常使用的password密码模式（提供用户 名+密码换取token）。