领域建模驱动后端合规边界与JWT令牌安全策略设计 - 第4节

4.1 JWT 结构：Header、Payload、Signature

JSON Web Token（JWT）是一种紧凑的、URL 安全的令牌格式，用于在各方之间以 JSON 对象的形式安全传输声明信息。一个 JWT 由三个 Base64URL 编码的部分组成，以点号（.）分隔：Header.Payload.Signature。

4.1.1 Header（头部）

Header 通常包含两部分信息：令牌类型（typ）和签名算法（alg）。

• typ（Type）： 声明令牌类型，固定为 "JWT"。
• alg（Algorithm）： 签名算法，如 HS256（HMAC-SHA256）、RS256（RSA-SHA256）等。

{
  "alg": "HS256",
  "typ": "JWT"
}

4.1.2 Payload（载荷）

Payload 包含声明（Claims），即关于实体（通常是用户）和附加数据的 JSON 对象。声明分为三类：

{
  "sub": "1234567890",
  "name": "张三",
  "iat": 1516239022,
  "exp": 1516242622,
  "role": "admin"
}

4.1.3 Signature（签名）

Signature 用于验证消息在传输过程中未被篡改，并确保令牌的完整性。签名过程如下：

1. 将 Base64URL 编码后的 Header 和 Payload 用点号连接。
2. 使用 Header 中指定的算法（如 HMAC-SHA256）和密钥（Secret）对上述字符串进行加密。
3. 将生成的签名进行 Base64URL 编码。

// 伪代码示例
signature = HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

4.2 JWT 与 Session 的区别

JWT 和 Session 是两种主流的身份认证与状态管理机制，它们在存储位置、扩展性、安全性等方面存在本质差异。理解这些差异对于设计合规的后端架构至关重要。

4.2.1 核心差异深度解析

• 状态存储位置： Session 是“有状态”的，服务端必须维护一个会话存储；JWT 是“无状态”的，所有用户信息都编码在令牌中，服务端只需验证签名。
• 扩展性： 在微服务架构中，JWT 的“无状态”特性使得每个服务都可以独立验证令牌，无需访问共享 Session 存储，极大简化了水平扩展。
• 安全性考量： Session 的敏感数据在服务端，客户端仅持有随机 ID，安全性更高；JWT 的 Payload 仅 Base64 编码，必须假设其内容可被客户端读取，因此绝不能存放密码、密钥等敏感信息。
• 吊销能力： Session 可以立即删除服务端记录实现强制下线；JWT 在签发后直到过期前都有效，服务端无法主动使其失效，必须配合黑名单或短过期时间（如 15 分钟）加刷新令牌机制来弥补。