分布式鉴权JWT领域建模与架构设计 - 第1节
1.1 分布式系统鉴权的核心挑战
在单体应用向分布式架构演进的过程中，鉴权（Authentication & Authorization）面临的根本性变化在于：用户请求可能被集群中任意一个无状态节点处理。传统的“在本地内存中维护登录Session”的模式，在分布式环境下暴露出多个结构性难题。
核心矛盾：分布式系统要求服务节点无状态化以支持水平扩展，但鉴权信息天然具有“状态”——即用户已登录的事实。如何在不引入有状态中心的前提下，让每个节点都能独立验证用户身份，是分布式鉴权架构设计的起点。
分布式鉴权的四大挑战
| 挑战维度 | 问题描述 | 传统Session方案痛点 |
|---|---|---|
| 会话共享 | 用户登录后，后续请求可能被负载均衡分发到不同节点 | Session默认存储在单节点内存，其他节点无法识别 |
| 存储扩展 | 海量用户并发登录，Session数据量线性增长 | 内存占用过高，需引入Redis等外部存储，增加架构复杂度 |
| 跨域/跨服务 | 微服务架构下，一次业务请求可能跨越多个服务 | Session ID在服务间传递需额外透传机制，且每个服务都要查询Session存储 |
| 安全边界 | Session ID是纯随机字符串，服务端无法验证其内容是否被篡改 | 依赖HTTPS和存储安全，一旦泄露可被任意伪造 |
1.2 传统Session vs JWT：两种鉴权范式
理解Session与JWT的本质差异，需要从“状态存储位置”这一根本维度切入。Session是服务端有状态方案，JWT是客户端自包含方案。
核心对比
| 对比维度 | 传统Session | JWT（JSON Web Token） |
|---|---|---|
| 状态存储 | 服务端内存/Redis | 客户端（Token自身携带） |
| 验证方式 | 查询存储比对Session ID | 本地验签（公钥/密钥） |
| 扩展性 | 需共享存储或Session复制 | 天然无状态，节点独立验证 |
| 跨域支持 | 需配置Cookie Domain或额外透传 | 通过HTTP Header携带，天然跨域 |
| 数据承载 | 仅Session ID，用户信息需二次查询 | Payload可携带用户角色、权限等声明 |
| 失效控制 | 服务端可主动销毁（如踢人下线） | 生效期内无法主动失效（需配合黑名单） |
架构选型警示：不要因为JWT“无状态”就认为它一定优于Session。如果业务场景要求服务端主动控制会话生命周期（如强制下线、多端互踢），纯JWT方案反而需要额外引入黑名单机制，此时Session + Redis方案可能更直接。
两种鉴权流程对比图
下图直观展示了Session与JWT在请求验证路径上的本质区别：Session需要服务端查询存储，JWT则通过本地验签完成。
1.3 JWT核心优势与适用场景
JWT（RFC 7519）是一种自包含的、紧凑的、URL安全的令牌格式。其核心优势并非来自加密算法，而是来自“将信任边界从存储转移到签名”这一架构思想。
JWT的三大核心优势
- 无状态验证：服务端无需维护会话存储，每个节点通过公钥独立验证Token合法性，水平扩展零障碍。
- 自包含载荷：Token内部可直接携带用户ID、角色、权限范围等声明，减少后续查询次数。
- 跨域/跨服务友好：通过HTTP Authorization Header传递，不受Cookie Domain限制，天然适配微服务、移动端、单页应用。
典型适用场景
| 场景 | 推荐度 | 说明 |
|---|---|---|
| 微服务API网关鉴权 | ★★★★★ | 网关验签后向下游透传用户身份，下游无需重复验证 |
| 单页应用（SPA） | ★★★★★ | Token存储在localStorage，通过Header携带，无Cookie跨域问题 |
| 移动端App | ★★★★☆ | 原生App可安全存储Token，配合刷新机制实现长会话 |
| 第三方开放API | ★★★★☆ | 作为Bearer Token发放给第三方，服务端无需维护第三方会话 |
| 服务间内部调用 | ★★★☆☆ | 适合短生命周期调用，但需注意Token泄露风险 |
| 需要服务端主动踢人 | ★★☆☆☆ | 需配合黑名单或Token版本号，增加复杂度 |
JWT令牌结构示意图
一个JWT由三部分组成：Header（头部）、Payload（载荷）、Signature（签名），以Base64URL编码后通过点号（.）连接。
架构要点：JWT的签名机制保证了完整性（Integrity）而非机密性（Confidentiality）。Payload仅经过Base64编码，并未加密。切勿在JWT的Payload中存放密码、信用卡号等敏感信息。如需加密载荷，应使用JWE（JSON Web Encryption）。
JWT的边界意识
JWT并非万能方案。在以下场景中，传统Session或混合方案可能更合适：
- 需要服务端主动管理会话：如强制用户下线、多设备互踢、账号封禁。JWT生效期内无法撤销，需引入黑名单或Token版本号。
- Token体积敏感：JWT携带的声明越多，Token越长，每次请求都会携带，可能影响网络开销。
- 刷新机制复杂：Access Token过期后需通过Refresh Token获取新Token，增加了客户端和服务端的逻辑复杂度。