微服务架构下权限校验应放在API网关还是资源服务层？-java教程-PHP中文网

微服务架构下权限校验应放在API网关还是资源服务层？

在微服务化改造中，细粒度权限控制应在资源服务（即各业务微服务）内部实现，API网关仅负责统一认证、令牌转发与客户端特异性安全策略（如CSRF、CORS），而非替代业务层的授权逻辑。

在微服务架构下，权限校验应在资源服务（即各业务微服务）内部实现，api网关仅负责统一认证、令牌转发与客户端特异性安全策略（如csrf、cors），而非替代业务层的授权逻辑。

将细粒度（fine-grained）权限检查下沉至资源服务器，是当前业界主流的最佳实践。原因在于：权限逻辑高度耦合于业务语义——例如“财务专员可审批单笔≤5万元的报销申请”或“区域经理仅能查看本辖区客户数据”，这类规则随业务迭代频繁变更，由对应微服务团队自主维护，既保障职责清晰，又避免网关成为权限逻辑的集中瓶颈和发布阻塞点。

✅ 正确的权限流设计

网关职责明确：
- 验证 accessToken 的签名、有效期与基本受众（aud）；
- 执行跨域（CORS）、会话安全（如 CSRF Token 校验）、速率限制等通道层安全策略；
- 通过 Token Relay（如 Spring Cloud Gateway 的 TokenRelayFilter）将原始 accessToken 透传至下游服务，不解析、不修改、不缓存用户权限数据。
资源服务自主授权：

FlagEval
FlagEval是一款AI模型评测工具，（天秤）大模型评测平台，由智源研究院推出。

下载
- 接收网关转发的 accessToken，解析其 JWT Claims（如 sub, roles, scope, 或自定义 permissions 数组）；
- 基于声明信息执行业务级鉴权——例如 Spring Security 中使用 @PreAuthorize("hasAuthority('ORDER_DELETE')") 或自定义 PermissionEvaluator；
- 对于复杂权限模型（如角色→权限→属性多级嵌套），推荐在资源服务内构建权限决策服务（如基于 RBAC + ABAC 混合模型），从令牌中提取基础身份标识后，查询本地或专用权限服务获取动态权限上下文。

// 示例：Spring Boot 资源服务中基于 JWT Claim 的权限校验
@RestController
public class OrderController {

    @GetMapping("/orders/{id}")
    @PreAuthorize("@permissionService.canAccessOrder(authentication, #id)")
    public Order getOrder(@PathVariable String id) {
        return orderService.findById(id);
    }
}

// 自定义权限服务（可集成数据库/缓存）
@Component
public class PermissionService {
    public boolean canAccessOrder(Authentication auth, String orderId) {
        String userId = (String) auth.getPrincipal();
        // 查询订单归属、用户角色、数据级权限策略...
        return permissionRepository.hasDataLevelAccess(userId, orderId);
    }
}

⚠️ 关于 OIDC 流程与网关角色的关键提醒

切勿在网关侧触发 Authorization Code Flow（尤其带 openid scope）：
这会导致非浏览器客户端（如移动端 App、后台定时任务、第三方系统）无法调用 API——因为网关会尝试重定向响应（302），而这些客户端无法处理跳转。正确做法是：所有客户端（Web SPA、Mobile、Backend）各自独立完成 OIDC 登录流程，向授权服务器（AS）换取 accessToken，再携带该令牌调用网关。网关只需验证令牌有效性，并在失败时返回标准 401 Unauthorized。
网关的真正价值在于“适配层”而非“决策层”：
例如，针对 Web 客户端使用 Secure HttpOnly Cookie 存储会话，网关可解包 Cookie、校验 CSRF Token、注入 JWT 到请求头；而对 Mobile 客户端，则直接透传 Authorization: Bearer <token></token>。这种差异化处理让后端微服务保持协议中立（只认 JWT），大幅提升复用性与可测试性。

✅ 总结建议

层级	责任	是否推荐
API 网关	认证（JWT 验签）、令牌透传、CORS/CSRF、限流	✅ 是
资源服务	角色/权限/数据级细粒度授权、业务规则执行	✅ 必须
网关内做权限判断	解析 `accessToken` 并执行 `hasRole('ADMIN')` 类逻辑	❌ 否（违反关注点分离）