文章目录
学习链接
实战干货！Spring Cloud Gateway 整合 OAuth2.0 实现分布式统一认证授权！
spring-cloud-gateway-oauth2的github代码地址 - 已克隆到gitee
微服务权限终极解决方案，Spring Cloud Gateway + Oauth2 实现统一认证和鉴权！
SpringBoot WebFlux集成WebFluxSecurity做登录权限验证
微服务认证方案
微服务认证方案目前有很多种，每个企业也是大不相同，但是总体分为两类，如下：
-
网关只负责转发请求，认证鉴权交给每个微服务控制
-
统一在网关层面认证鉴权，微服务只负责业务
-
网关自定义网关（全局）过滤器作权限校验
-
搭建1个认证中心（里面继续使用原来的security oauth2，不是webflux的），网关整合security作权限校验（但是注意这里的实现是webflux，底层用的是netty，而不是传统的tomcat容器了，因此写法上有比较大的区别，需要对webflux有一定了解。最关键的是注意配置的2个过滤器：AuthenticationWebFilter-管认证的 和 AuthorizationWebFilter-管授权的，顺序定义在SecurityWebFiltersOrder中），当security对用户身份处理后，用户权限通过之后（注意：即使认证不通过，权限也可以通过，关键是看权限是否允许，可类比原来的security来理解），再会交给网关过滤器处理（此时如果可以解析到用户身份的话，可以将用户身份添加到请求头中），然后经过网关路由转发给对应的微服务。
-
先来说说第一种方案，有着很大的弊端，如下：
-
代码耦合严重，每个微服务都要维护一套认证鉴权
-
无法做到统一认证鉴权，开发难度太大
-
（之前有使用过这种实现，定义个公共认证模块的jar包，各个微服务引入这个jar包，jar包中引入了security，开启全局校验，各个微服务可以使用注解，各个微服务可以覆盖jar包中的关键配置类实现。但是，后来遇到微服务之间互相调用时也得把这个令牌给带上去以供被调用的微服务作权限校验的问题，这样就导致权限校验管理混乱。所以还不如直接在网关层作校验，然后校验通过后，将用户身份权限写成请求头，在网关转发的时候携带给下面的微服务，后面微服务如果有必要作权限校验的话，可以使用AOP自主实现校验逻辑）
第二种方案明显是比较简单的一种，优点如下：
-
实现了统一的认证鉴权，微服务只需要各司其职，专注于自身的业务
-
代码耦合性低，方便后续的扩展