JWT令牌伪造检测与后端安全合规错误码断言工程案例 - 第1节

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

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

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
部分 名称 内容说明 示例（解码后）
Header 头部 令牌类型（typ）和签名算法（alg），如 HS256、RS256 {"alg":"HS256","typ":"JWT"}
Payload 载荷 声明（Claims），包含实体信息（如用户 ID、角色）和元数据（如签发时间 iat、过期时间 exp） {"sub":"1234567890","name":"John Doe","iat":1516239022}
Signature 签名 对 Header 和 Payload 的防篡改校验值，使用指定算法和密钥生成 HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

关键安全点：Header 中的 alg 字段若被篡改为 "none" 或弱算法（如 "HS256" 降级为 "HS1"），攻击者可绕过签名验证。后端必须严格校验 alg 白名单。

1.2 JWT 工作原理：签发、传输与验证

JWT 的工作流程分为三个核心阶段：签发（Issuance）、传输（Transmission）和验证（Verification）。下图展示了从客户端登录到后端验证的完整闭环：

JWT 工作原理流程图 JWT 签发与验证流程 客户端 （浏览器/移动端） 认证服务器 （签发 JWT） 资源服务器 （验证 JWT） 1. 登录凭证 2. 返回 JWT 3. 请求携带 JWT（Authorization: Bearer） 验证步骤 ① 解析 Header/Payload ② 校验签名 ③ 检查 exp/nbf/iss 4. 返回资源/错误
  1. 签发：客户端提交登录凭证（用户名/密码），认证服务器验证通过后，生成包含用户身份和权限声明的 JWT，并使用服务端密钥签名。
  2. 传输：客户端收到 JWT 后，通常存储在 localStorage 或 Cookie 中，并在后续请求的 HTTP Header 中携带：Authorization: Bearer <token>。
  3. 验证：资源服务器（或 API 网关）从请求头中提取 JWT，验证签名完整性、检查过期时间（exp）和签发者（iss），通过后提取 Payload 中的用户信息进行授权。

无状态设计：JWT 本身包含所有用户信息，服务端无需维护会话存储（Session Store），天然适合分布式和微服务架构。

1.3 JWT 与 Session 对比：核心差异与选型依据

Session 是传统的服务端会话管理方案，JWT 是新兴的无状态令牌方案。两者在存储位置、扩展性、安全性等方面存在显著差异：

对比维度 Session（服务端会话） JWT（JSON Web Token）
存储位置 服务端内存/Redis，客户端仅存 Session ID 客户端持有完整令牌，服务端无状态
扩展性 需要共享 Session 存储（如 Redis 集群），水平扩展复杂 天然支持水平扩展，任何服务节点均可独立验证
跨域支持 受限于 Cookie 同源策略，跨域需额外配置 通过 HTTP Header 传递，天然支持跨域
实时吊销 服务端直接删除 Session，实时生效 令牌签发后无法直接吊销，需配合黑名单或短有效期
数据体积 Session ID 很小（通常 32 字节），网络开销低 Payload 携带用户信息，体积较大（通常 500B~2KB）
安全风险 CSRF 攻击风险较高，需 Token 或 SameSite 防护 XSS 攻击可窃取令牌，需防范令牌泄露和重放
适用场景 传统单体应用、服务端渲染、对实时吊销要求高的系统 微服务、移动端、单页应用（SPA）、API 网关

工程选型建议：不要盲目选择 JWT。如果系统需要频繁吊销用户令牌（如后台管理系统），Session + Redis 方案更合适；如果系统面向第三方开放 API 或需要跨域无状态认证，JWT 是更优解。

1.4 JWT 结构详解：Header、Payload、Signature 的工程细节

1.4.1 Header（头部）

Header 通常包含两个字段：令牌类型（typ）和签名算法（alg）。算法字段是安全校验的核心：

{
  "alg": "HS256",   // 签名算法，常见值：HS256、RS256、ES256
  "typ": "JWT"      // 令牌类型，固定为 "JWT"
}
  • 对称算法（HS256/HS384/HS512）：使用同一个密钥进行签名和验证，适合内部服务间通信。
  • 非对称算法（RS256/ES256）：使用私钥签名、公钥验证，适合第三方分发或开放 API。
  • 安全红线：后端必须拒绝 alg: "none" 的令牌，并限制算法白名单，防止算法混淆攻击。

1.4.2 Payload（载荷）

Payload 包含声明（Claims），分为三类：

声明类型 说明 示例字段
注册声明 JWT 标准预定义字段，提供互操作性 iss（签发者）、sub（主题）、aud（受众）、exp（过期时间）、nbf（生效时间）、iat（签发时间）、jti（唯一标识）
公共声明 在 IANA 注册或使用 URI 避免冲突的自定义字段 "https://api.example.com/role": "admin"
私有声明 双方约定的自定义字段，不要求全局唯一 "user_id": 12345、"permissions": ["read","write"]

安全实践：不要在 Payload 中存储敏感信息（如密码、信用卡号），因为 Payload 仅 Base64URL 编码，并未加密。如需加密，应使用 JWE（JSON Web Encryption）。

1.4.3 Signature（签名）

签名是 JWT 防篡改的核心保障。以 HMAC-SHA256 为例，签名生成过程如下：

// 伪代码：签名生成
signature = HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

验证时，接收方使用相同的算法和密钥重新计算签名，并与令牌中的签名比对。若不一致，则拒绝请求。

密钥管理：对称算法（HS256）的密钥必须妥善保管，不可硬编码在代码中；非对称算法（RS256）的私钥仅由签发服务持有，公钥可安全分发。

1.5 JWT 与 Session 的架构对比图

下图从架构视角对比 Session 和 JWT 在分布式系统中的数据流差异：

Session 与 JWT 架构对比 Session vs JWT 架构对比 Session 架构 客户端 服务端 A Redis Session 服务端 A 从 Redis 读取 Session 服务端 B 也需连接同一 Redis JWT 架构 客户端 服务端 A 公钥/密钥 服务端 A 本地验证 JWT 签名 服务端 B 独立验证，无需共享存储

从架构对比可以看出：Session 方案依赖集中式缓存（如 Redis）实现会话共享，扩展时需保证所有服务节点连接同一存储；JWT 方案每个服务节点独立验证令牌，无需共享存储，扩展性更优，但令牌吊销需要额外机制（如黑名单或短有效期）。

← 上一章 📖 返回目录 下一章 →