权限校验是否应该在 Spring Cloud Gateway 中进行？
这是一个非常关键且常见的架构问题！“权限校验是否应该在 Spring Cloud Gateway 中进行？” 答案是：部分可以，但要分场景，不能一概而论。
下面我们从合理性、适用场景、风险与最佳实践几个维度来深入分析：
一、为什么有人想在 Gateway 做权限校验？
✅ 优势（合理之处）
| 优势 | 说明 |
|---|---|
| 统一入口，避免重复 | 所有请求经过网关，认证逻辑只需写一次 |
| 提前拦截，节省资源 | 无效请求（如未登录、Token 过期）在网关就被拒绝，不进入下游服务 |
| 解耦业务服务 | 业务服务无需关心认证细节，专注核心逻辑 |
| 便于集中监控 | 登录失败、非法访问等行为可在网关统一记录 |
🎯 适合场景：身份认证（Authentication），比如验证 JWT Token 是否有效、是否过期。
二、为什么不能把所有权限校验都放在 Gateway？
❌ 核心问题：权限 ≠ 认证
- 认证（Authentication）：你是谁？（验证身份）→ ✅ 适合在 Gateway
- 授权（Authorization）：你能做什么？（验证权限）→ ❌ 通常不适合在 Gateway
⚠️ 在 Gateway 做细粒度权限校验的风险
| 问题 | 详细说明 |
|---|---|
| 业务耦合 | 权限规则（如“只有部门经理能删除员工”）属于业务逻辑，放在网关会导致网关了解太多业务细节 |
| 数据依赖 | 权限判断往往需要查询数据库（如用户角色、资源归属），网关不应直接访问业务数据库 |
| 维护困难 | 每新增一个接口权限，都要修改网关配置或代码，违背“单一职责原则” |
| 性能瓶颈 | 网关变成“全能胶水层”，承担过多逻辑，影响高并发性能 |
| 测试复杂 | 权限逻辑分散在网关和业务服务，难以单元测试和调试 |
🌰 举个例子
假设有一个接口：DELETE /api/employees/{id}
- 认证：检查请求头是否有有效 Token → ✅ 可在 Gateway 做
- 授权：检查当前用户是否是该员工的直属领导 → ❌ 必须在 员工服务（Employee Service） 中做，因为只有它知道组织架构关系
三、推荐的权限分层架构（最佳实践）
🔐 分层职责明确
| 层级 | 职责 | 技术实现 |
|---|---|---|
| Gateway 层 | 粗粒度认证 • Token 格式校验 • 签名验证 • 是否过期 • 黑名单检查 | • 自定义 GlobalFilter • 集成 Spring Security OAuth2 Resource Server |
| 业务服务层 | 细粒度授权 • 角色/权限校验 • 数据级权限（如只能看自己部门） • 业务规则校验 | • Spring Security @PreAuthorize• 自定义权限注解 • 服务内权限服务 |
四、Gateway 中如何安全地做认证？
✅ 推荐做法：只做 Token 有效性验证
// 示例：Gateway 中的认证过滤器（仅验证 JWT）
@Component
public class AuthFilter implements GlobalFilter, Ordered {@Overridepublic Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {String token = extractToken(exchange);if (token == null) {return unauthorized(exchange, "Missing token");}try {// 仅验证 Token 签名和过期时间（不查数据库！）JwtClaims claims = JwtHelper.parseToken(token, "secret-key");// 将用户信息放入 Header，传递给下游ServerHttpRequest request = exchange.getRequest().mutate().header("X-User-Id", claims.getUserId()).header("X-User-Roles", String.join(",", claims.getRoles())).build();return chain.filter(exchange.mutate().request(request).build());} catch (Exception e) {return unauthorized(exchange, "Invalid token");}}private Mono<Void> unauthorized(ServerWebExchange exchange, String msg) {exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);return exchange.getResponse().setComplete();}@Overridepublic int getOrder() {return -100; // 优先级高于路由过滤器}
}
🔑 关键点：
- 不访问数据库：只做无状态验证（签名 + 过期时间）
- 透传用户信息：将解析出的用户 ID、角色等放入 Header，供下游使用
- 快速失败：无效 Token 直接返回 401，不转发请求
五、什么情况下可以在 Gateway 做简单授权？
虽然不推荐，但在以下特定场景可以谨慎使用：
| 场景 | 说明 | 示例 |
|---|---|---|
| 路由级权限 | 某些路由只对特定角色开放 | /admin/** 仅允许 ADMIN 角色访问 |
| 黑白名单 | IP 或用户 ID 黑名单拦截 | 恶意爬虫 IP 直接拒绝 |
| 功能开关 | 某个功能模块临时关闭 | 返回 403 并提示“功能维护中” |
⚠️ 前提：这些规则简单、静态、不依赖业务数据，且可通过配置动态调整。
六、总结：权限校验的合理分工
| 功能 | 是否适合在 Gateway | 建议位置 |
|---|---|---|
| Token 有效性验证 | ✅ 是 | Gateway |
| 用户身份解析 | ✅ 是（仅解析，不查库） | Gateway |
| 角色/权限校验 | ❌ 否 | 业务服务 |
| 数据级权限控制 | ❌ 否 | 业务服务 |
| 敏感操作二次验证 | ❌ 否 | 业务服务 |
| IP/设备黑白名单 | ✅ 是（简单规则） | Gateway |
💡 黄金法则：
Gateway 负责“你是谁”，业务服务负责“你能干什么”。
这样既能发挥网关的统一入口优势，又能保持微服务的内聚性和可维护性。