4. JWT深入解析：JWT结构、签名算法与令牌选型

JWT（JSON Web Token）是现代分布式认证授权体系中最核心的令牌格式。理解JWT的结构、签名机制及其与Opaque Token的差异，是设计高可用、高安全SSO平台的基础。本节将从架构视角拆解JWT的每一层，并给出选型决策依据。

4.1 JWT结构：三段式令牌的构成

一个标准的JWT由三个Base64URL编码的部分组成，以点号（.）分隔：Header.Payload.Signature。每一段都承载着特定的语义和职责。

4.1.1 Header（头部）

Header通常包含两个字段：typ（类型）和alg（签名算法）。示例：

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

• typ：固定为"JWT"，表示这是一个JWT令牌。
• alg：签名算法标识，常见值包括HS256、RS256、ES256等。该字段决定了签名验证的数学原理。

4.1.2 Payload（载荷）

Payload包含三类声明（Claims）：

4.1.3 Signature（签名）

签名是对Header和Payload的完整性保护。生成过程如下：

signature = sign( base64url(header) + "." + base64url(payload), secret_or_private_key )

验证方使用相同的算法和密钥，对Header和Payload重新计算签名，并与令牌中的签名比对。若一致，则令牌未被篡改。

4.2 签名算法：HS256 vs RS256

签名算法是JWT安全性的基石。HS256和RS256是最常用的两种算法，它们在密钥管理、性能和安全模型上有本质区别。

4.2.1 HS256 签名与验证流程

// 签名（认证服务器）
signature = HMAC-SHA256( base64url(header) + "." + base64url(payload), shared_secret )

// 验证（认证服务器或持有共享密钥的服务）
expected_signature = HMAC-SHA256( base64url(header) + "." + base64url(payload), shared_secret )
if signature == expected_signature: 验证通过

4.2.2 RS256 签名与验证流程

// 签名（认证服务器，使用私钥）
signature = RSA-SHA256( base64url(header) + "." + base64url(payload), private_key )

// 验证（任何服务，使用公钥）
expected_signature = RSA-SHA256( base64url(header) + "." + base64url(payload), public_key )
if signature == expected_signature: 验证通过

4.3 JWT vs Opaque Token：架构选型决策

Opaque Token（不透明令牌）是另一种常见的令牌格式，通常是一个随机字符串，本身不包含任何用户信息。JWT和Opaque Token各有优劣，选型取决于架构需求。

4.3.1 架构选型建议

• 优先选择JWT的场景：
  • 微服务架构，服务间需要无状态认证。
  • API网关需要快速验证令牌，避免每次转发都调用认证中心。
  • 令牌生命周期短（如15-30分钟），撤销需求不强烈。
• 优先选择Opaque Token的场景：
  • 需要即时撤销用户会话（如用户主动登出、管理员封禁账号）。
  • 令牌生命周期长（如数小时或数天），撤销能力至关重要。
  • 令牌中需要携带大量敏感信息，但不想暴露给客户端。

4.4 JWT结构、签名与令牌选型全景图

下图展示了JWT的三段式结构、HS256与RS256的签名验证流程，以及JWT与Opaque Token在架构中的不同角色。

4.5 关键架构决策总结

• 签名算法选型：在分布式SSO架构中，优先选择RS256。它允许每个微服务通过公开的公钥独立验证JWT，无需共享密钥，降低了密钥泄露风险。
• 令牌格式选型：对于高并发、低延迟的API网关和微服务，使用JWT作为Access Token；对于需要即时撤销能力的Refresh Token，使用Opaque Token。
• 安全底线：永远不要在JWT的Payload中存放敏感数据；始终验证签名；使用HTTPS传输令牌；设置合理的过期时间（建议Access Token 15-30分钟）。