今天这篇文章介绍一下Spring Cloud Gateway整合OAuth2.0**实现认证授权，转发于码猿技术专栏
微服务认证方案
微服务认证方案目前有很多种，每个企业也是大不相同，但是总体分为两类，如下：
- 网关只负责转发请求，认证鉴权交给每个微服务控制
- 统一在网关层面认证鉴权，微服务只负责业务
你们公司目前用的哪种方案？
先来说说第一种方案，有着很大的弊端，如下：
- 代码耦合严重，每个微服务都要维护一套认证鉴权
- 无法做到统一认证鉴权，开发难度太大
第二种方案明显是比较简单的一种，优点如下：
- 实现了统一的认证鉴权，微服务只需要各司其职，专注于自身的业务
- 代码耦合性低，方便后续的扩展
下面陈某就以第二种方案为例，整合Spring Cloud Gateway+Spring Cloud Security 整合出一套统一认证鉴权案例。
案例架构
开始撸代码之前，先来说说大致的认证鉴权流程，架构如下图：
大致分为四个角色，如下：
- 客户端：需要访问微服务资源
- 网关：负责转发、认证、鉴权
- OAuth2.0授权服务：负责认证授权颁发令牌
- 微服务集合：提供资源的一系列服务。
大致流程如下：
1、客户端发出请求给网关获取令牌
2、网关收到请求，直接转发给授权服务
3、授权服务验证用户名、密码等一系列身份，通过则颁发令牌给客户端
4、客户端携带令牌请求资源，请求直接到了网关层
5、网关对令牌进行校验（验签、过期时间校验....）、鉴权（对当前令牌携带的权限）和访问资源所需的权限进行比对，如果权限有交集则通过校验，直接转发给微服务
6、微服务进行逻辑处理
针对上述架构需要新建三个服务，分别如下：
我们实际项目当中也是这样，网关服务(gateway)、认证服务(auth-server)、业务服务隔离开的，有一次我在迁移服务时，认证授权服务和业务服务耦合在一起请求接口会失败。
问题记录：我们auth认证和其他接口放到一起存在一个问题，请求新开发的接口请求不到。
