后端安全合规缓存一致性治理的JWT签名算法与缓存验证流程 - 第1节

1.1 什么是 JWT

JSON Web Token（JWT）是一种基于 JSON 格式的开放标准（RFC 7519），用于在各方之间以紧凑且自包含的方式安全地传输信息。JWT 通常用于身份认证和信息交换场景，其核心特点是：自包含——令牌本身携带了所有必要的用户信息和元数据，无需服务端维护会话状态。

JWT 的典型应用场景包括：

• 单点登录（SSO）：一次认证，多个系统共享登录态。
• API 鉴权：客户端携带 JWT 访问后端资源，服务端验证签名即可。
• 信息交换：使用签名保证数据在传输过程中未被篡改。

1.2 JWT 的组成结构

一个完整的 JWT 由三个部分通过 . 连接而成：Header、Payload、Signature。格式如下：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

1.2.1 Header（头部）

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

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

• alg：签名算法，常见值有 HS256（HMAC-SHA256）、RS256（RSA-SHA256）、ES256（ECDSA-SHA256）。
• typ：令牌类型，固定为 JWT。

1.2.2 Payload（载荷）

Payload 是 JWT 的核心数据部分，包含声明（Claims）。声明分为三类：

1.2.3 Signature（签名）

Signature 用于验证 JWT 的完整性和真实性。其生成过程如下：

signature = HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

服务端使用相同的密钥和算法对 Header 和 Payload 重新计算签名，并与 JWT 携带的签名比对。若不一致，则判定令牌被篡改。

1.3 JWT 与 Session 的区别

JWT 和传统的 Session 认证机制在架构设计、存储方式、扩展性等方面存在本质差异。下表从多个维度进行对比：

1.3.1 核心差异详解

• 无状态 vs 有状态：JWT 自包含用户信息，服务端无需查询数据库即可完成认证；Session 需要服务端根据 Session ID 查找对应的会话数据。
• 扩展性：JWT 在微服务架构中优势明显，每个服务独立验证签名即可；Session 需要所有服务共享同一个会话存储（如 Redis 集群），增加运维复杂度。
• 吊销能力：Session 可以即时删除服务端数据实现强制下线；JWT 在过期前无法主动失效，通常需要引入黑名单机制或使用短过期时间 + Refresh Token 方案。