JWT 令牌安全解析实战
一、场景:排查"登录态失效"
前端最常见的报错之一是 401 Unauthorized。多数情况下问题出在 JWT 令牌本身:过期了、签名算法不匹配、或者服务端签发的字段与客户端校验逻辑不一致。与其在代码里加 console.log,不如直接把令牌拆开看。
二、JWT 的三段式结构
JWT 由三段 Base64Url 编码的文本用点号连接:Header.Payload.Signature。打开 JWT 解析,粘贴完整令牌,工具会立即分三栏展示:
- Header:声明签名算法(如 HS256)与令牌类型;
- Payload:实际的业务数据,包括标准声明(iss 签发者、exp 过期时间、sub 主题)与自定义字段(用户 ID、角色等);
- Signature:对前两段的签名,用于校验完整性(纯前端无法验证签名,因为需要服务端密钥)。
三、核对 exp 过期时间
排查登录态失效,第一步看 Payload 里的 exp 字段。它是一个 Unix 时间戳(秒级)。把它复制到 时间戳转换,即可看到具体的过期日期时间,与当前时间对比:
- 已过期 → 问题定位完成,刷新令牌逻辑未生效;
- 未过期但服务端仍返回 401 → 检查
iss、aud是否与服务端校验配置一致。
四、手动拆解(理解原理)
想理解 JWT 的编码原理,可以手动拆一次。以 Payload 段为例:
- 复制两个点号之间的第二段文本;
- 打开 Base64 编解码,解码这一段(注意 JWT 用的是 Base64Url 变体,字符
-和_分别替代+和/,且无填充号); - 得到的原文是一段 JSON,粘贴到 JSON 工具 格式化,即可看到全部声明字段。
走完这个流程你会直观地认识到:JWT 的 Payload 只是编码而非加密,任何人都能解码看到内容。这就是为什么绝不能把密码、手机号等敏感明文放进 JWT。
五、常见问题
- 解析结果乱码:确认复制时没有丢失字符,JWT 三段之间必须正好两个点号;从日志里复制时注意别把换行符带进来;
- exp 是 10 位还是 13 位:JWT 标准是秒级 10 位;若拿到 13 位说明服务端误用了毫秒时间戳,可在时间戳转换工具里切换秒 / 毫秒模式核对;
- alg 为 none:签名算法声明为 none 的令牌极度危险,任何服务端都不应接受,遇到请立刻反馈后端。
六、小结
JWT 解析配合时间戳转换,可以在一分钟内定位绝大多数登录态问题。同时它也是一个教学工具:亲手解一次 Payload,你对"JWT 不是加密"这件事的印象会非常深刻。