JWT 安全实践指南：结构、算法与常见误区

JWT（JSON Web Token，RFC 7519）是如今最流行的无状态认证载体之一，但也是被误解最深的。本文围绕它的结构、签名算法与常见误区展开，并说明如何安全地调试生产令牌。

一、JWT 的三段结构

一个 JWT 由三部分以点号连接：Header.Payload.Signature。Header 声明签名算法；Payload 携带声明（claims）如 sub、exp、iat；Signature 用于校验前两段未被篡改。

关键事实：JWT 默认不加密

Header 与 Payload 只是 Base64URL 编码，任何人拿到 Token 都能直接读出内容。签名仅提供完整性保证，不提供机密性。因此 Payload 中绝不能出现密码、手机号明文等敏感信息。你可以用本站 JWT 工具粘贴任意 Token 验证这一点——解码不需要任何密钥。

二、HS256 与密钥管理

HS256（HMAC-SHA256）是最常用的对称签名算法，签发与校验使用同一个密钥。工程上有几条纪律：

• 密钥长度不低于 256 位（32 字节），且来自密码学安全随机源；
• 密钥只存在于服务端配置（环境变量/KMS），绝不入库、绝不下发客户端、绝不写进仓库；
• 多服务共享密钥时，任何持有方都能签发合法 Token——签发权要收敛到认证服务；
• 怀疑泄露立即轮换密钥，配合较短的 exp 控制影响面。

三、四个常见误区

1. “JWT 是加密的”——不是，见上文；需要加密应使用 JWE。
2. “签名算法写死在服务端”——校验方必须显式限定允许的算法，历史上 alg: none 与 RS256→HS256 混淆攻击都源于盲目信任 Header 声明。
3. “Token 无法主动失效”——纯 JWT 无状态、无法单独吊销。退出登录、改密等场景要么接受自然过期，要么引入服务端黑名单/版本号，后者实际放弃了部分无状态收益。
4. “exp 只是建议”——校验方必须检查 exp/nbf，缺失时应视为无效。

四、安全地调试生产令牌

排查线上认证问题时，你需要解码真实 Token、校验签名是否与密钥匹配。如果把它粘贴到服务端处理的在线工具里，等于把生产凭证发给了第三方。本站的 JWT 工具解码与 HS256 签名校验全部在浏览器本地完成，断网也可使用，适合这类场景；本站 另一篇文章详细说明了如何验证这一点。

小结

JWT 的安全边界取决于三件事：Payload 里放了什么、密钥如何管理、校验方是否严格。Token 本身只是编码加签名——把敏感数据留在服务端，把签名算法与过期校验做严，它就是可靠的认证载体。