微服务架构下的认证与授权挑战
在单体应用向微服务架构演进的过程中，认证与授权体系面临的根本性转变在于：从“单一信任域”走向“多信任域”协作。传统单体应用中的 Session 共享、集中式权限校验等成熟模式，在分布式环境下逐一失效。本章聚焦三大核心挑战：分布式会话问题、无状态认证需求以及服务间信任传递的复杂性，并分析其对 JWT 令牌刷新与权限矩阵集成的直接影响。
1. 分布式会话问题
单体应用中，用户登录后的会话状态通常存储在应用服务器的内存 Session 中，负载均衡器通过粘滞会话（Sticky Session）将同一用户的请求始终路由到同一节点。微服务架构下，服务实例多、动态扩缩容频繁，这种模式面临严重问题：
- Session 漂移：用户请求被路由到不同实例时，无法获取之前的会话数据。
- 集中式 Session 存储瓶颈：引入 Redis 等外部存储虽能解决漂移，但增加了网络延迟和单点风险。
- 跨服务会话共享困难：不同微服务可能使用不同的会话存储机制，难以统一管理。
核心矛盾：分布式环境要求会话状态在多个无状态服务节点间透明共享，但传统 Session 机制本质上是“有状态”的，与微服务的弹性伸缩原则相悖。
2. 无状态认证需求
为解决分布式会话问题，业界普遍转向无状态认证模式。服务端不再保存会话状态，而是将用户身份与权限信息编码在令牌中，由客户端持有并在每次请求时携带。JWT（JSON Web Token）正是这一模式的核心载体。
无状态认证带来的关键变化：
| 维度 | 传统有状态 Session | 无状态 JWT |
|---|---|---|
| 存储位置 | 服务端内存 / Redis | 客户端（令牌本身） |
| 扩展性 | 需共享存储或粘滞会话 | 天然支持水平扩展 |
| 吊销能力 | 直接删除 Session | 需黑名单或短有效期 |
| 跨服务传递 | 需透传 Session ID | 直接携带 JWT 即可 |
然而，无状态认证并非没有代价。令牌一旦签发，在有效期内无法被服务端主动撤销，这直接催生了短生命周期 Access Token + 长生命周期 Refresh Token 的刷新机制，成为后续章节的核心议题。
3. 服务间信任传递的复杂性
在微服务架构中，一个用户请求往往需要经过多个服务协作完成。例如：API 网关 → 用户服务 → 订单服务 → 库存服务。如何让下游服务信任上游传递过来的用户身份？这涉及信任传递问题。
常见的信任传递模式对比：
| 模式 | 描述 | 安全性 | 复杂度 |
|---|---|---|---|
| Token 透传 | 下游服务直接验证原始 JWT | 高（需验证签名） | 低 |
| Token 换发 | 每个服务用自身凭证换取新令牌 | 中（需管理服务凭证） | 高 |
| 内部 JWT | 网关验证后签发内部专用 JWT | 高（隔离外部令牌） | 中 |
常见误区：直接将用户 JWT 透传给所有下游服务，可能导致权限越界。例如，订单服务本不应看到用户的支付令牌信息。正确的做法是在网关层进行令牌裁剪或换发，仅传递当前服务所需的最小权限声明。
下图展示了微服务架构中认证与授权的典型信任传递路径，以及各环节面临的核心挑战：
4. 挑战对 JWT 刷新与权限矩阵的影响
上述三大挑战直接决定了 JWT 令牌刷新策略与权限矩阵集成方案的设计方向：
- 分布式会话 → 短生命周期 Access Token：服务端不保存会话，令牌必须短命（通常 15-30 分钟），降低泄露风险，同时配合 Refresh Token 实现无感续期。
- 无状态认证 → 令牌自包含权限声明：权限矩阵必须编码在 JWT 的 claims 中，服务端无需查库即可完成鉴权，但需控制声明大小避免令牌膨胀。
- 信任传递 → 网关级权限裁剪与换发：API 网关作为信任边界，负责验证原始令牌、按服务需求裁剪权限声明、签发内部令牌，实现最小权限原则。
设计启示：在后续章节中，我们将基于“Access Token 短命 + Refresh Token 长命 + 权限声明按服务裁剪”的核心模式，构建完整的令牌刷新与权限矩阵集成方案。该模式既解决了分布式会话问题，又实现了无状态认证，同时通过网关层控制信任传递范围。