面经策

微服务架构下如何做统一认证鉴权？网关和服务内部怎么分工？ ​

  • 标签：Spring Security、认证授权、后端

🏛 业务架构师 ​

微服务架构下的统一认证鉴权，我按"网关集中+服务自治"的分层模型讲：

总体设计：

  1. 认证统一收口（网关层）：认证中心（OIDC/OAuth2，如 Keycloak/自建）负责登录与签发 JWT；API 网关统一验签——校验签名、过期、黑名单，通过后把解析出的用户身份（userId、tenantId、角色）以可信 Header（X-User-Id 等，内部网络+网关清洗入站同名头，防伪造）或原 Token 传递给下游。价值：验签逻辑一处实现、一处升级（换算法不用改 30 个服务）；未认证流量在网关被拦，内部服务少一层攻击面；
  2. 授权服务自治（各服务）：认证解决"你是谁"（网关已保证），授权"你能干什么"必须由各业务服务自己判断——权限模型（RBAC）+资源归属（这个订单是不是你的）只有业务知道。实现：服务读网关传递的身份 + 本地权限判定（@PreAuthorize + 权限数据）；权限变更通过事件广播（改权限 → 发 MQ → 各服务刷新本地权限缓存）；
  3. 服务间调用（M2M）：client_credentials 模式的服务 Token 或 mTLS——服务身份与用户身份双层传递（"服务 A 代表用户 U 调用服务 B"：转发用户 Token 或 on-behalf-of 换发）。

分工口诀：网关管认证与粗粒度（路由级）拦截，服务管细粒度（功能+数据）授权。

避坑清单：内部服务别裸奔（默认零信任：内网也应校验来源）；权限缓存要有失效机制（否则踢人不生效）；链路上透传的身份要做防伪造清洗；审计日志在网关与服务两级留痕（谁、何时、调了什么）。这套分层是 2026 年微服务安全的默认架构，本质是把安全做成"基础设施"而不是每个团队的作业题。

🏗 系统架构师 ​

微服务统一认证鉴权 = 网关集中验 + 服务分布式鉴的分层体系，我按"三层分工"讲：

第一层：统一认证（Authentication 收口在网关/认证中心）：

  • 认证中心（Authorization Server）：OIDC 体系签发 JWT（用户登录、第三方授权码+PKCE）；
  • 网关统一验签：所有外部请求过网关——验 JWT 签名/exp/受众，失败 401 即拒；通过后注入可信身份头（X-User-Id、X-Roles——从 JWT claims 解出），剥离外部传入的同名头（防伪造，这是关键细节）；
  • 内部服务信任网关（网络层面隔离：服务端口不对公网，零信任可再加一层内部校验）。

第二层：服务内部鉴权（Authorization 就地执行）：

  • 粗粒度：路由/网关层做（路径 × 角色矩阵——挡明显越界）；
  • 细粒度（业务规则/数据级）：只能在各服务内做（订单服务才知道"这个订单归不归这个用户"）——服务从网关注入的可信头重建 SecurityContext（过滤器一次封装），再用 @PreAuthorize 表达业务规则；
  • 服务间调用（M2M）：client_credentials 令牌（服务身份）+ 用户上下文透传（原始 JWT 转发或内部声明换发）——服务身份与用户身份双轨：审计要能回答"哪个服务代表哪个用户"。

第三层：横切治理：

  • 密钥与轮换：JWKS 端点分发公钥、网关与服务定期轮换验证密钥；
  • 内省 vs 验签权衡：JWT 本地验签（零网络、作废弱）vs 不透明令牌 + 集中内省（即时作废、多一跳）——按安全等级分服务配置；
  • 统一审计链（traceId + 用户身份贯穿）、限流配额（按用户/租户在网关）。

反模式警示：每个服务自己登录（认证逻辑碎片化）、网关只转发不验签（每个服务裸验一遍重复且易漏）、鉴权全在网关（数据级判断网关做不了）——认证集中、授权分布，是这套架构的一句话总纲。

💻 全栈开发专家 ​

微服务统一认证鉴权，我的标准架构：网关集中认证 + 服务自治鉴权。

职责分工：

客户端 → API 网关（Spring Cloud Gateway）
   ├─ 【认证】验 JWT（验签/过期/黑名单）→ 失败 401
   ├─ 【粗授权】路由级 ACL（/order/** 需登录、/admin/** 需 ADMIN）
   ├─ 注入信任头：X-User-Id / X-Roles（或原样透传 JWT）
   └─ 限流/熔断/审计
        ↓ 内网（服务间信任边界）
   业务服务（无状态，信任网关注入的身份）
   ├─ 【细授权】@PreAuthorize 业务权限（order:refund）
   └─ 【数据权限】资源归属校验（orderId 属于当前用户？）

网关做什么（横向通用安全收口）：

  1. JWT 验签（JWKS 拉取授权中心公钥，本地缓存）、exp/nbf 校验、Redis 黑名单/版本号检查；
  2. 路由级权限（哪些路径白名单、哪些要登录、哪些要特定角色）；
  3. 全局限流、IP 黑白名单、审计日志；
  4. 信任头防伪造：网关强制剥离外部传入的 X-User-Id 再注入自己的——这行配置是安全命门。

服务做什么（垂直业务知识）：

  1. 方法级权限（业务点权限在业务方手里最合理）；
  2. 数据权限/归属校验（水平越权只能在懂业务的地方防）；
  3. 服务间调用：服务信任（mTLS）或 token relay（透传用户 token 保完整链路身份）。

认证中心：独立服务（Spring Authorization Server/Keycloak）：登录、签发/刷新/吊销 token、用户与角色管理。

两条铁律：1. 服务不重复做网关的事（验签一次就好，性能与一致性都赢）；2. 网关不做业务授权（它不懂「这个订单是谁的」）。见过反例：所有权限写在网关配置里，业务方每加一个接口都要发网关工单——架构走形。