Spring Cloud Gateway 整合 OAuth2.0 实现分布式统一认证授权①

大家好，我是不才陈某~

这是《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实现认证授权，涉及到的知识点有点多，有不清楚的可以看下陈某的往期文章。

文章目录如下：

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

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

你们公司目前用的哪种方案？

先来说说第一种方案，有着很大的弊端，如下：

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

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

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

下面陈某就以第二种方案为例，整合Spring Cloud Gateway+Spring Cloud Security 整合出一套统一认证鉴权案例。

案例架构
开始撸代码之前，先来说说大致的认证鉴权流程，架构如下图：

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

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

大致流程如下：

1、客户端发出请求给网关获取令牌

2、网关收到请求，直接转发给授权服务

3、授权服务验证用户名、密码等一系列身份，通过则颁发令牌给客户端

4、客户端携带令牌请求资源，请求直接到了网关层

5、网关对令牌进行校验（验签、过期时间校验....）、鉴权（对当前令牌携带的权限）和访问资源所需的权限进行比对，如果权限有交集则通过校验，直接转发给微服务

6、微服务进行逻辑处理

针对上述架构需要新建三个服务，分别如下：

案例源码目录如下：

 
文章转自公众号：码猿技术专栏