微服务权限终极解决方案（spring-cloud-gateway-oauth2）
我们理想的微服务权限解决方案应该是这样的，认证服务负责认证，网关负责校验认证和鉴权，其他API服务负责处理自己的业务逻辑。安全相关的逻辑只存在于认证服务和网关服务中，其他服务只是单纯地提供服务而没有任何安全相关逻辑。
通过认证服务( oauth2-auth )进行统一认证，然后通过网关（ oauth2-gateway ）来统一校验认证和鉴权。采用Nacos作为注册中心，Gateway作为网关，使用nimbus-jose-jwtJWT库操作JWT令牌。
接下来搭建网关服务，它将作为Oauth2的资源服务、客户端服务使用，对访问微服务的请求进行统一的校验认证和鉴权操作
最后我们搭建一个API服务，它不会集成和实现任何安全相关逻辑，全靠网关来保护它
在此之前先启动我们的 Nacos 和 Redis 服务，然后依次启动 oauth2-auth 、 oauth2-gateway 及 oauth2-api 服务
我这里测试使用的 Docker 跑的单机版的 Nacos
github.com/it-wwh/spring-cloud-gateway-oauth2
SpringCloud系列之网关gateway-11.权限认证-分布式session替代方案
前面我们了解了Gateway组件的过滤器，这一节我们就探讨一下Gateway在分布式环境中的一个具体用例-用户鉴权。
从我们开始学JavaEE的时候，就被洗脑式灌输了一种权限验证的标准做法，那就是将用户的登录状态保存到HttpSession中，比如在登录成功后保存一对key-value值到session，key是userId而value是用户后台的真实ID。接着创建一个ServletFilter过滤器，用来拦截需要登录才能访问的资源，假如这个请求对应的服务端session里找不到userId这个key，那么就代表用户尚未登录，这时候可以直接拒绝服务然后重定向到用户登录页面。
大家应该都对session机制比较熟悉，它和cookie是相互依赖的，cookie是存放在用户浏览器中的信息，而session则是存放在服务器端的。当浏览器发起服务请求的时候就会带上cookie，服务器端接到Request后根据cookie中的jsessionid拿到对应的session。
由于我们只启动一台服务器，所以在登录后保存的session始终都在这台服务器中，可以很方便的获取到session中的所有信息。用这野路子，我们一路搞定了各种课程作业和毕业设计。结果一到工作岗位发现行不通了，因为所有应用都是集群部署，在一台机器保存了的session无法同步到其他机器上。那我们有什么成熟的解决方案吗？
分布式环境下的解决方案
Session复制是最容易先想到的解决方案，我们可以把一台机器中的session复制到集群中的其他机器。比如Tomcat中也有内置的session同步方案，但是这并不是一个很优雅的解决方案，它会带来以下两个问题：
Timing问题 同步需要花费一定的时间，我们无法保证session同步的及时性，也就是说，当用户发起的两个请求分别落在不同机器上的时候，前一个请求写入session的信息可能还没同步到所有机器，后一个请求就已经开始执行业务逻辑了，这不免引起脏读幻读。
数据冗余 所有服务器都需要保存一份session全集，这就产生了大量的冗余数据
反向代理：绑定IP或一致性Hash
这个方案可以放在Nignx网关层做的，我们可以指定某些IP段的请求落在某个指定机器上，这样一来session始终只存在一台机器上。不过相比前一种session复制的方法来说，绑定IP的方式有更明显的缺陷：
负载均衡 在绑定IP的情况下无法在网关层应用负载均衡策略，而且某个服务器出现故障的话会对指定IP段的来访用户产生较大影响。对网关层来说该方案的路由规则配置也极其麻烦。
IP变更 很多网络运营商会时不时切换用户IP，这就会导致更换IP后的请求被路由到不同的服务节点处理，这样一来就读不到前面设置的session信息了
为了解决第二个问题，可以通过一致性Hash的路由方案来做路由，比如根据用户ID做Hash，不同的Hash值落在不同的机器上，保证足够均匀的分配，这样也就避免了IP切换的问题，但依然无法解决第一点里提到的负载均衡问题。
这个方案解决了前面提到的大部分问题，session不再保存在服务器上，取而代之的是保存在redis中，所有的服务器都向redis写入/读取缓存信息。
在Tomcat层面，我们可以直接引入tomcat-redis-session-manager组件，将容器层面的session组件替换为基于redis的组件，但是这种方案和容器绑定的比较紧密。另一个更优雅的方案是借助spring-session管理redis中的session，尽管这个方案脱离了具体容器，但依然是基于Session的用户鉴权方案，这类Session方案已经在微服务应用中被淘汰了。
分布式Session的替代方案
To think out of box guys~让我们把session抛到脑后，看看现在流行的两种认证方式：
大家一定用过现在比较流行的第三方登录，比如我们通过微信扫码登录就可以登录某个应用的在线系统，但是这个应用并不知道我的微信用户名和密码。这便是我们要介绍的第一个鉴权方案-OAuth 2.0。
OAuth 2.0是一个开放授权标准协议，它允许用户让第三方应用访问该用户在某服务的特定私有资源，但是不提供账号密码信息给第三方应用。在上面的例子中，微信就相当于一个第三方应用，我们通过OAuth 2.0
拿微信登录第三方应用的例子来说：
Auth Grant 在这一步Client发起Authorization Request到微信系统（比如通过微信内扫码授权），当身份验证成功后获取Auth Grant
Get Token 客户端拿着从微信获取到的Auth Grant，发给第三方引用的鉴权服务，换取一个Token，这个Token就是访问第三方应用资源所需要的令牌
访问资源 最后一步，客户端在请求资源的时候带上Token令牌，服务端验证令牌真实有效后即返回指定资源
我们可以借助Spring Cloud中内置的
spring-cloud-starter-oauth2
组件搭建OAuth 2.0的鉴权服务，OAuth 2.0的协议还涉及到很多复杂的规范，比如角色、客户端类型、授权模式等。这一小节我们暂且不深入探讨OAuth 2.0的实现方式，先来看另外一个更轻量级的授权方案：JWT鉴权。
JWT也是一种基于Token的鉴权机制，它的基本思想就是通过用户名+密码换取一个Access Token
相比OAuth 2.0来说，它的鉴权过程更加简单，其基本流程是这样的：
JWT的Access Token由三个部分构成，分别是Header、Payload和Signature，我们分别看下这三个部分都包含了哪些信息：
Header 头部声明了Token的类型（JWT类型）和采用的加密算法（HS256）
{'typ': 'JWT',
'alg': 'HS256'}
Payload 这一段包含的信息相当丰富，你可以定义Token签发者、签发和过期时间、生效时间等一系列属性，还可以添加自定义属性。服务端收到Token的时候也同样可以对Payload中包含的信息做验证，比如说某个Token的签发者是“Feign-API”，假如某个接口只能允许“Gateway-API”签发的Token，那么在做鉴权服务时就可以加入Issuer的判断逻辑。
Signature 它会使用Header和Payload以及一个密钥用来生成签证信息，这一步会使用Header里我们指定的加密算法进行加密
目前实现JWT的开源组件非常多，如果决定使用这个方案，只要添加任意一个开源JWT实现的依赖项到项目中的pom文件，然后在加解密时调用该组件来完成。
第五篇：Spring Cloud Eureka 权限认证
Eureka注册中心的管理界面以及服务注册时，没有任何认证机制，如果这个地址有公网IP的话，必然能直接访问到，这样是不安全的，安全性比较差，如果其它服务恶意注册一个同名服务，但是实现不同，可能就有风险了
如何解决这个问题呢？加用户认证即可，通过spring-security来开始用户认证
开启安全认证，并且配置用户信息
重新启动注册中心，访问 此时浏览器会提示你输入用户名和密码，输入正确后才能继续访问Eureka提供的管理页面。
注册中心开启认证后，项目中的注册中心地址的配置也需要改变,需要加上认证的用户名和密码
9. SpringCloud之权限校验方案
1、保存用户信息 到 服务器内存,用于会话保持
2、jsessionId存储到浏览器的cookie里，登录后每次访问都要 带上这个，与用户信息绑定,如果jsessionId被人盗取,容易遭受csrf 跨域攻击。
3、如果登录用户过多, 服务内保存的session信息 占用内存较大
由于项目组件的变大，往往会把 应用部署多份，再用nginx 做负载均衡，提高系统的并发量。
这时 由服务器来 存储session 就会出现出现问题：
接下来就引入了 分布式session的 方案：
不讲 session信息存储在 服务器内部,引入第三方中间件如redis,mongodb,将session统一放到 第三方中间件这里，然后 再统一从 这取。
因为在微服务应用中,网关是 系统 所有流量的入口。在网关中 进行权限校验，理论上是可行的。
当请求携带登录返回的token时, 请求网关, 由网关来 向认证服务器 发起 校验token 的请求。
但是这样还有一个很重要的问题, 就是下游服务 不做权限校验的话，那么 下游服务 的接口 就完全相当于裸奔的, 别人知道下游服务的接口地址，就可以直接调用, 非常的危险。
所以，在这种方案中,一般 还会加上ip白名单校验, 下游服务 只允许 网关 发过来的请求,其他 来源不明的请求,直接在防火墙 拦截调。以保证, 下游服务的接口 只能网关转发过来并且 是 网关鉴权通过的。
理论上 网关 服务器是不需要进行权限校验的，因为 zuul 服务器没有接口， 不需要从 网关 调用业务接口，网关 只做简单的路由工作。下游系统在获取到 token 后，通过 过滤器把 token 发到认证服务器校验该 token 是否有效，如果认证服务器校验通过就会携带 这个 token 相关的验证信息传回给下游系统，下游系统根据这个返回结果就知道该 token 具 有的权限是什么了。
这种方式 不会有 接口裸奔的风险, 也不用加ip白名单校验,更可以 进行方法级别的校验,粒度更细。
不管 是只在网关层做权限校验,还是只在下游服务做权限校验,在oauth2.0的权限校验模型中, 所有 校验token的过程,都需要与 认证服务器 进行一次 交互, 这点 不太好,多了一次 网络请求。
spring cloud gateway + oauth2 实现网关统一权限认证
1. 由于 spring cloud gateway 是基于 WebFlux 框架实现的，该网关作为资源服务器时不能使用 @EnableResourceServer 注解，需要使用 @EnableWebFluxSecurity 注解来配置安全过滤链。
2. 在 springboot 2.2 之前的版本中，安全框架对应的是 spring-security 5.14，该版本只实现了基于 id token (jwk) 的认证，而我当前项目中的认证服务组件是基于 org.springframework.cloud:spring-cloud-starter-oauth2 框架开发，使用的是秘钥签名的 access token，所以网关服务组件需要使用 springboot 2.2 + spring security 5.2 来处理 jws。
3. 现有项目使用了 gradle 构建，是一个多模块的结构，其中主模块引入了 2.1.2.RELEASE 版本的 org.springframework.boot 插件，用来确保各模块中 spring 组件的版本统一，此时子模块是无法通过修改插件版本号或重新引入插件来改变模块中 springboot 的版本，所以网关模块想用要引入 springboot 2.2 的话，就得脱离主模块，或者将插件引入的操作直接下放到各个子模块的构建过程中。
4. org.springframework.cloud:spring-cloud-starter-oauth2 中 org.springframework.security.jwt.crypto.sign.MacSigner 支持使用短密码的 HMACSHA256 签名算法，NimbusReactiveJwtDecoder 不支持短密码。