Gateway 鉴权场景：网关统一鉴权 + 业务应用决定放行规则

目录

一、核心设计原则（一句话总结）

二、具体实现方案（最主流、最推荐）

1. 整体流程

2. 具体技术实现（Spring Cloud Gateway 为例）

（1）业务服务：定义注解 + 扫描接口路由

（2）业务服务：启动时自动上报路由权限规则

（3）Gateway：拉取规则 + 全局过滤器统一鉴权

三、更轻量的简化方案（中小型项目常用）

四、为什么要这么设计？（面试加分回答）

五、面试标准回答（你可以直接背）

总结

这是微服务架构中最标准、最常用的鉴权方案：Gateway 只做「鉴权执行」，业务服务只做「放行规则配置」，职责完全解耦。

本文直接给你讲企业落地的通用实现方案，清晰、可直接面试回答，也能直接开发用。

一、核心设计原则（一句话总结）

Gateway 不关心业务，只做 “校验 token 是否有效 + 是否需要放行”； 业务服务定义 “哪些接口公开、哪些需要权限”，把规则告诉 Gateway。

二、具体实现方案（最主流、最推荐）

1. 整体流程

1. 业务服务（如订单、用户服务）：在自己的接口上标注权限注解（如 @Anonymous 免鉴权、@RequireRole("ADMIN")）。
2. 业务服务启动时：把接口权限规则自动上报到配置中心 / 数据库。
3. Gateway 实时拉取规则：知道哪些路径不需要登录、哪些需要什么角色 / 权限。
4. 请求进入 Gateway：
   • 匹配规则 → 公开接口：直接放行
   • 私有接口：校验 Token → 无效直接拦截 → 有效则转发

2. 具体技术实现（Spring Cloud Gateway 为例）

（1）业务服务：定义注解 + 扫描接口路由

业务服务自己决定哪些接口不用登录：

1// 免登录注解（业务服务定义）
2@Target({ElementType.METHOD})
3@Retention(RetentionPolicy.RUNTIME)
4public @interface Anonymous {
5}
6
7// 控制器里使用
8@RestController
9@RequestMapping("/user")
10public class UserController {
11
12    // 登录接口 → 业务决定免鉴权
13    @Anonymous
14    @PostMapping("/login")
15    public Result login() {}
16
17    // 获取用户信息 → 需要鉴权
18    @GetMapping("/info")
19    public Result info() {}
20}
21

（2）业务服务：启动时自动上报路由权限规则

项目启动时，扫描所有 @Anonymous、@RequirePermission 注解， 把 URL + 是否需要鉴权 + 需要的权限 上报到：

• Nacos / Apollo（配置中心）
• 或 Redis / MySQL

示例上报格式（Gateway 能读懂）：

1[
2  { "url": "/user/login", "auth": false },
3  { "url": "/user/info", "auth": true, "roles": ["USER"] },
4  { "url": "/order/**", "auth": true, "perms": ["order:query"] }
5]
6

（3）Gateway：拉取规则 + 全局过滤器统一鉴权

Gateway 只做一件事： 拿请求路径 → 匹配规则 → 决定是否校验 Token

核心过滤器伪代码：

1@Component
2public class AuthFilter implements GlobalFilter {
3
4    @Autowired
5    private AuthRuleService authRuleService; // 拉取业务服务上报的规则
6
7    @Override
8    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
9        // 1. 获取当前请求路径
10        String path = exchange.getRequest().getPath().toString();
11
12        // 2. 查询规则：是否需要鉴权（由业务服务决定！）
13        AuthRule rule = authRuleService.getRule(path);
14
15        // 3. 业务说不需要鉴权 → 直接放行
16        if (!rule.isAuth()) {
17            return chain.filter(exchange);
18        }
19
20        // 4. 需要鉴权 → Gateway 执行校验（Token、签名、过期等）
21        String token = exchange.getRequest().getHeader("token");
22        if (!JwtUtil.verify(token)) {
23            return unauthorizedResponse(exchange);
24        }
25
26        // 5. 校验通过 → 转发
27        return chain.filter(exchange);
28    }
29}
30

三、更轻量的简化方案（中小型项目常用）

如果不想做「自动上报」，可以用配置文件模式，同样满足： 业务决定放行规则，Gateway 只执行。

1. 每个业务服务提供一个 white-list.yml

1anonymous:  
2  urls:  
3    - /user/login  
4    - /file/upload/**  

2. 交给 Gateway 加载
3. Gateway 统一拦截、放行、鉴权

优点：简单、稳定、无侵入。 缺点：不能自动扫描注解，需要手动维护（但很多公司就这样用）。

四、为什么要这么设计？（面试加分回答）

1. 职责分离
   • Gateway：只做通用安全拦截（无业务逻辑）
   • 业务服务：只做自身接口权限定义
2. 扩展性强 新增服务 → 只需要业务配置规则，Gateway 完全不用改
3. 统一安全入口 所有鉴权收口在网关，避免业务服务漏写鉴权
4. 性能更好 非法请求在网关层直接拦截，不会打到后端服务

五、面试标准回答（你可以直接背）

我们的方案是：Gateway 统一负责鉴权逻辑的执行，业务服务负责定义哪些接口需要鉴权、哪些不需要。

具体实现：

1. 业务服务通过注解（如 @Anonymous）标记公开接口；
2. 服务启动时自动扫描接口，把权限规则上报到配置中心或 Redis；
3. Gateway 实时拉取所有服务的权限规则；
4. 请求进入网关后，根据规则判断是否需要鉴权，需要则校验 Token，不需要直接放行。

这种模式做到了权限控制在业务，鉴权执行在网关，职责清晰、易于维护。

总结

1. 控制权分离：Gateway 执行鉴权，业务服务定义规则
2. 实现方式：注解 + 规则上报 + Gateway 全局过滤器
3. 优点：解耦、统一入口、易扩展、安全
4. 两种方案：自动上报（大型项目）、配置白名单（中小型项目）

《Gateway 鉴权场景：网关统一鉴权 + 业务应用决定放行规则》 是转载文章，点击查看原文。