Spring Cloud OAuth2 + JWT微服务统⼀认证⽅案

认证：验证⽤户的合法身份，⽐如输⼊⽤户名和密码，系统会在后台验证⽤户名和密码是否合法，合法的前提下，才能够进⾏后续的操作，访问受保护的资源

微服务架构下统⼀认证场景

分布式系统的每个服务都会有认证需求，如果每个服务都实现⼀套认证逻辑会⾮常冗余，考虑分布式系统共享性的特点，需要由独⽴的认证服务处理系统认证的请求

微服务架构下统⼀认证思路

基于Session的认证⽅式
在分布式的环境下，基于session的认证会出现⼀个问题，每个应⽤服务都需要在session中存储⽤户身份信息，通过负载均衡将本地的请求分配到另⼀个应⽤服务需要将session信息带过去，否则会重新认证。我们可以使⽤Session共享、Session黏贴等⽅案。

Session⽅案也有缺点，⽐如基于cookie，移动端不能有效使⽤等

基于token的认证⽅式

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

OAuth2开放授权协议/标准

OAuth（开放授权）是⼀个开放协议/标准，允许⽤户授权第三⽅应⽤访问他们存储在另外的服务提供者上的信息，⽽不需要将⽤户名和密码提供给第三⽅应⽤或分享他们数据的所有内容。

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

结合“使⽤QQ登录拉勾”这个场景拆分理解上述那句话
⽤户：我们⾃⼰
第三⽅应⽤：拉勾⽹
另外的服务提供者：QQ
OAuth2是OAuth协议的延续版本，但不向后兼容OAuth1即完全废⽌了OAuth1

OAuth2协议⻆⾊和流程

拉勾⽹要开发使⽤QQ登录这个功能的话，那么拉勾⽹是需要提前到QQ平台进⾏登记的（否则QQ凭什
么陪着拉勾⽹玩授权登录这件事）
1）拉勾⽹——登记——>QQ平台
2）QQ 平台会颁发⼀些参数给拉勾⽹，后续上线进⾏授权登录的时候（刚才打开授权⻚⾯）需要携带这些参数client_id ：客户端id（QQ最终相当于⼀个认证授权服务器，拉勾⽹就相当于⼀个客户端了，所以会给⼀个客户端id），相当于账号

secret：相当于密码

什么情况下需要使⽤OAuth2？
第三⽅授权登录的场景：⽐如，我们经常登录⼀些⽹站或者应⽤的时候，可以选择使⽤第三⽅授权登录的⽅式，⽐如：微信授权登录、QQ授权登录、微博授权登录等，这是典型的 OAuth2 使⽤场景。

单点登录的场景：如果项⽬中有很多微服务或者公司内部有很多服务，可以专⻔做⼀个认证中⼼（充当认证平台⻆⾊），所有的服务都要到这个认证中⼼做认证，只做⼀次登录，就可以在多个授权范围内的服务中⾃由串⾏

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

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

Spring Cloud OAuth2介绍

Spring Cloud OAuth2 是 Spring Cloud 体系对OAuth2协议的实现，可以⽤来做多个微服务的统⼀认证（验证身份合法性）授权（验证权限）。通过向OAuth2服务（统⼀认证授权服务）发送某个类型的grant_type进⾏集中认证和授权，从⽽获得access_token（访问令牌），⽽这个token是受其他微服务信任的。

注意：使⽤OAuth2解决问题的本质是，引⼊了⼀个认证授权层，认证授权层连接了资源的拥有者，在授权层⾥⾯，资源的拥有者可以给第三⽅应⽤授权去访问我们的某些受保护资源。
Spring Cloud OAuth2构建微服务统⼀认证服务思路

注意：在我们统⼀认证的场景中，Resource Server其实就是我们的各种受保护的微服务，微服务中的各种API访问接⼝就是资源，发起http请求的浏览器就是Client客户端（对应为第三⽅应⽤）