2. JWT 结构解析:Header、Payload、Signature 的组成与作用

JWT(JSON Web Token)是一种紧凑的、自包含的认证授权数据载体。一个完整的 JWT 由三个独立的部分组成,它们通过 点号(.) 连接,形成如下结构:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

每一段都经过 Base64URL 编码,分别对应 Header(头部)、Payload(载荷) 和 Signature(签名)。下面逐一拆解其组成与作用。

2.1 Header(头部)—— 算法与类型声明

Header 是 JWT 的第一段,通常包含两个核心字段:令牌类型(typ)和签名算法(alg)。

字段 含义 常见值 说明
typ 令牌类型 JWT 固定为 JWT,表示这是一个 JSON Web Token
alg 签名算法 HS256 / RS256 / ES256 指定签名使用的加密算法,HS256 为对称,RS256 为非对称

解码后的 Header 示例:

{
  "alg": "HS256",
  "typ": "JWT"
}
作用:Header 告诉验证方“这个令牌用什么算法签名”,验证方必须使用相同的算法进行签名校验。如果攻击者篡改 alg 为 none,服务端未做校验则可能导致安全漏洞。

2.2 Payload(载荷)—— 声明数据

Payload 是 JWT 的第二段,存放实际的数据声明(Claims)。声明分为三类:

  • 注册声明(Registered Claims): 预定义的标准化字段,如 iss(签发者)、sub(主题)、aud(受众)、exp(过期时间)、iat(签发时间)、jti(JWT ID)。
  • 公共声明(Public Claims): 由使用方自定义,建议在 IANA JSON Web Token Registry 注册或使用命名空间避免冲突。
  • 私有声明(Private Claims): 双方约定使用的自定义字段,如 user_id、role、permissions。

解码后的 Payload 示例:

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022,
  "exp": 1516242622,
  "role": "admin"
}
声明类型 示例字段 是否必须 说明
注册声明 exp, iat, sub 推荐使用 提供标准语义,便于互操作
公共声明 https://example.com/is_admin 可选 建议使用 URI 避免冲突
私有声明 user_id, role 可选 双方约定,不对外公开
安全提醒:Payload 仅经过 Base64URL 编码,不是加密。任何人都可以解码读取其中的内容。严禁在 Payload 中存放密码、密钥、身份证号等敏感信息。

2.3 Signature(签名)—— 防篡改核心

Signature 是 JWT 的第三段,用于验证令牌在传输过程中是否被篡改,并确认签发者的身份。它的生成过程如下:

  1. 将 Header 和 Payload 分别进行 Base64URL 编码。
  2. 用点号连接编码后的 Header 和 Payload,形成签名输入字符串。
  3. 使用 Header 中指定的算法(如 HMAC-SHA256),结合一个密钥(Secret)对输入字符串进行签名。
  4. 将生成的签名进行 Base64URL 编码,得到 Signature 段。

伪代码表示:

signature = HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)
关键理解:Signature 依赖密钥。如果使用对称算法(HS256),签发和验证使用同一个密钥;如果使用非对称算法(RS256),签发使用私钥,验证使用公钥。服务端验证时,会重新计算签名并与 JWT 中的签名比对,不一致则直接拒绝。

2.4 三部分协作关系图

下图展示了 JWT 从生成到验证的完整流程,以及 Header、Payload、Signature 三者的协作关系:

JWT 三部分协作与验证流程 JWT 三部分协作与验证流程 Header(头部) Payload(载荷) Signature(签名) 完整 JWT Header.Payload.Signature Base64URL 编码 点号连接 自包含令牌 重新计算签名 比对签名是否一致 验证通过 / 拒绝 关键要点: 1. Header 声明算法,Payload 存放数据,Signature 保证完整性。 2. 签名使用密钥生成,任何对 Header 或 Payload 的篡改都会导致签名不匹配。 3. 服务端验证时,必须使用与签发时相同的算法和密钥(或公钥)重新计算签名。 4. 不要信任 alg: none,必须强制校验签名。

2.5 三部分对比总结

组成部分 编码方式 是否加密 核心作用 安全关注点
Header Base64URL 否 声明算法与类型 防止算法降级攻击(如 alg: none)
Payload Base64URL 否 存放声明数据 禁止存放敏感信息,注意 exp 校验
Signature Base64URL 否(但依赖密钥) 防篡改、身份验证 密钥安全存储,算法强度足够
实战口诀:Header 看算法,Payload 存数据,Signature 保安全。三部分缺一不可,任何一段被篡改,签名校验都会失败。