实战干货！Spring|实战干货！Spring Cloud Gateway 整合 OAuth2.0 实现分布式统一认证授权！实战干货！SpringCloudGateway整合

大家好，我是不才陈某~
这是《Spring Cloud 进阶》第15篇文章，往期文章如下：

五十五张图告诉你微服务的灵魂摆渡者Nacos究竟有多强？
openFeign夺命连环9问，这谁受得了？
阿里面试这样问：Nacos、Apollo、Config配置中心如何选型？这10个维度告诉你！
阿里面试败北：5种微服务注册中心如何选型？这几个维度告诉你！
阿里限流神器Sentinel夺命连环 17 问？
对比7种分布式事务方案，还是偏爱阿里开源的Seata，真香！(原理+实战)
Spring Cloud Gateway夺命连环10问？
Spring Cloud Gateway 整合阿里 Sentinel网关限流实战！
分布式链路追踪之Spring Cloud Sleuth夺命连环9问？
链路追踪自从用了SkyWalking，睡的真香！
3本书了，7万+字，10篇文章，《Spring Cloud 进阶》基础版 PDF
妹子始终没搞懂OAuth2.0，今天整合Spring Cloud Security 一次说明白！
OAuth2.0实战！使用JWT令牌认证！
OAuth2.0实战！玩转认证、资源服务异常自定义这些骚操作！

今天这篇文章介绍一下Spring Cloud Gateway整合OAuth2.0实现认证授权，涉及到的知识点有点多，有不清楚的可以看下陈某的往期文章。
文章目录如下：

实战干货！Spring|实战干货！Spring Cloud Gateway 整合 OAuth2.0 实现分布式统一认证授权！

文章图片

微服务认证方案微服务认证方案目前有很多种，每个企业也是大不相同，但是总体分为两类，如下：

网关只负责转发请求，认证鉴权交给每个微服务控制
统一在网关层面认证鉴权，微服务只负责业务

你们公司目前用的哪种方案？
先来说说第一种方案，有着很大的弊端，如下：

代码耦合严重，每个微服务都要维护一套认证鉴权
无法做到统一认证鉴权，开发难度太大

第二种方案明显是比较简单的一种，优点如下：

实现了统一的认证鉴权，微服务只需要各司其职，专注于自身的业务
代码耦合性低，方便后续的扩展

下面陈某就以第二种方案为例，整合Spring Cloud Gateway+Spring Cloud Security 整合出一套统一认证鉴权案例。
案例架构开始撸代码之前，先来说说大致的认证鉴权流程，架构如下图：

文章图片

大致分为四个角色，如下：

客户端：需要访问微服务资源
网关：负责转发、认证、鉴权
OAuth2.0授权服务：负责认证授权颁发令牌
微服务集合：提供资源的一系列服务。

大致流程如下：
1、客户端发出请求给网关获取令牌
2、网关收到请求，直接转发给授权服务
3、授权服务验证用户名、密码等一系列身份，通过则颁发令牌给客户端
4、客户端携带令牌请求资源，请求直接到了网关层
5、网关对令牌进行校验（验签、过期时间校验....）、鉴权（对当前令牌携带的权限）和访问资源所需的权限进行比对，如果权限有交集则通过校验，直接转发给微服务
6、微服务进行逻辑处理
针对上述架构需要新建三个服务，分别如下：

名称	功能
oauth2-cloud-auth-server	OAuth2.0认证授权服
oauth2-cloud-gateway	网关服务
oauth2-cloud-order-service	订单资源服务

案例源码目录如下：

文章图片

认证授权服务搭建很多企业是将认证授权服务直接集成到网关中，这么做耦合性太高了，这里陈某直接将认证授权服务抽离出来。
认证服务的搭建这里就不再细说了，上一篇文章中已经介绍的很清楚了：OAuth2.0实战！使用JWT令牌认证！
新建一个oauth2-cloud-auth-server模块，目录如下：

文章图片

和上篇文章不同的是创建了JwtTokenUserDetailsService这个类，用于从数据库中加载用户，如下：

文章图片

为了演示只是模拟了从数据库中查询，其中存了两个用户，如下：

user：具有ROLE_user权限
admin：具有ROLE_admin、ROLE_user权限

要想这个生效，还要在security的配置文件SecurityConfig中指定，如下图：

文章图片

另外还整合了注册中心Nacos，详细配置就不贴了，可以看源码。有不清楚Nacos，可以看之前文章：五十五张图告诉你微服务的灵魂摆渡者Nacos究竟有多强？

案例源码已经上传GitHub，关注公众号：码猿技术专栏，回复关键词： 9529 获取！

网关服务搭建网关使用的是Spring Cloud Gateway，网关如何搭建这里就不再细说了，有不清楚的可以看之前文章：Spring Cloud Gateway夺命连环10问？
新建一个oauth2-cloud-gateway模块，目录如下图：

文章图片

1、添加依赖
需要添加几个OAuth2.0相关的依赖，如下：

文章图片

2、JWT令牌服务配置
使用JWT令牌，配置要和认证服务的令牌配置相同，代码如下：

文章图片

3、认证管理器自定义
新建一个JwtAuthenticationManager，需要实现ReactiveAuthenticationManager这个接口。
认证管理的作用就是获取传递过来的令牌，对其进行解析、验签、过期时间判定。
详细代码如下：

文章图片

逻辑很简单，就是通过JWT令牌服务解析客户端传递的令牌，并对其进行校验，比如上传三处校验失败，抛出令牌无效的异常。
抛出的异常如何处理？如何定制返回的结果？
这里抛出的异常可以通过Spring Cloud Gateway的全局异常进行捕获，这个内容在Spring Cloud Gateway夺命连环10问？这篇文章有详细介绍。下面只贴出关键代码，如下：

文章图片

4、鉴权管理器自定义
经过认证管理器JwtAuthenticationManager认证成功后，就需要对令牌进行鉴权，如果该令牌无访问资源的权限，则不允通过。
新建JwtAccessManager，实现ReactiveAuthorizationManager，代码如下：

文章图片

这里的逻辑很简单，就是取出令牌中的权限和当前请求资源URI的权限对比，如果有交集则通过。
①处的代码什么意思？
这里是直接从Redis中取出资源URI对应的权限集合，因此实际开发中需要维护资源URI和权限的对应关系，这里不细说，为了演示，陈某直接在项目启动的时候向Redis中添加了两个资源的权限，代码如下：

文章图片

注意：实际开发中需要维护资源URI和权限的对应关系。

②处的代码什么意思？
这处代码就是取出令牌中的权限集合
③处的代码什么意思？
这处代码就是比较两者权限了，有交集，则放行。
5、令牌无效或者过期时定制结果
在第4步，如果令牌失效或者过期，则会直接返回，这里需要定制提示信息。
新建一个RequestAuthenticationEntryPoint，实现ServerAuthenticationEntryPoint，代码如下：

文章图片

6、无权限时定制结果
在第4步鉴权的过程中，如果无该权限，也是会直接返回，这里也需要定制提示信息。
新建一个RequestAccessDeniedHandler，实现ServerAccessDeniedHandler，代码如下：

文章图片

7、OAuth2.0相关配置
经过上述6个步骤，相关组件已经准备就绪，现在直接配置到OAuth2.0中。
新建SecurityConfig这个配置类，标注注解 @EnableWebFluxSecurity，注意不是 @EnableWebSecurity，因为Spring Cloud Gateway是基于Flux实现的。详细代码如下：

需要配置的内容如下：

认证过滤器，其中利用了认证管理器对令牌的校验
鉴权管理器、令牌失效异常处理、无权限访问异常处理
白名单配置
跨域过滤器的配置

8、全局过滤器定制
试想一下：网关层面认证鉴权成功后，下游微服务如何获取到当前用户的详细信息？
陈某这里是将令牌携带的用户信息解析出来，封装成JSON数据，然后通过Base64加密，放入到请求头中，转发给下游微服务。
这样一来，下游微服务只需要解密请求头中的JSON数据，即可获取用户的详细信息。
因此需要在网关中定义一个全局过滤器，用来拦截请求，解析令牌，关键代码如下：

上述代码逻辑如下：

检查是否是白名单，白名单直接放行
检验令牌是否存在
解析令牌中的用户信息
封装用户信息到JSON数据中
加密JSON数据
将加密后的JSON数据放入到请求头中

好了，经过上述8个步骤，完整的网关已经搭建成功了。

案例源码已经上传GitHub，关注公号：码猿技术专栏，回复关键词： 9529 获取！

订单微服务搭建由于在网关层面已经做了鉴权了（细化到每个URI），因此微服务就不用集成Spring Security单独做权限控制了。
因此这里的微服务也是相对比较简单了，只需要将网关层传递的加密用户信息解密出来，放入到Request中，这样微服务就能随时获取到用户的信息了。
新建一个oauth2-cloud-order-service模块，目录如下：