JWT 解码器 - 在线 JWT Token Decode & HS256 签名校验

1. 三十秒读懂一段 JWT

1. 把 token 粘进输入框，三段内容即时分开显示。
2. 先看 Header：alg 字段是签名算法（HS256/RS256/ES256），typ 通常是 JWT。
3. 再看 Payload：sub（主体）、exp（过期时间，Unix 秒）、iat（签发时间）、aud（受众）是四个最关键字段。
4. 时间类声明会以时间线展示（UTC + 相对偏移，如「两小时前过期」）；复制按钮留在输出区上方，不挡时间线。
5. alg=none 会标红警告；算法是否属于安全集合（HS256/RS256/ES256/PS256）也会提示。本页可做 HS256 校验；RS256/JWKS 验签不在本页范围。

2. HS256 与 RS256 怎么选

HS256 是对称签名：签发与验证共用一把密钥，实现简单、性能好，适合单体应用或完全互信的服务间通信；风险在于拿到密钥的任何一方既能验也能伪造。RS256 是非对称签名：私钥签发、公钥验证，第三方只凭公钥即可完成验证而无法伪造，配合标准化的 JWKS 端点（/.well-known/jwks.json）可以在不重新发版的情况下轮换密钥——多服务、开放平台、第三方接入的场景应当默认 RS256。

3. exp/nbf 校验的细节

• exp 是 Unix 秒级时间戳，不是毫秒——两套系统对时间戳单位的混用是「莫名提前过期」的头号原因。
• 校验要留时钟偏移容忍（leeway 设 30–60 秒）：分布式机器时钟漂移几秒很常见。
• nbf（not before）同理需要 leeway；iat 只做审计记录，不参与放行判断。
• 不要只在前端用 exp 判断登录态：服务端可能早已吊销该 token，前端 exp 检查只是 UX 层面的兜底。

4. 为什么生产校验必须在服务端

签名验证需要密钥或公钥，而浏览器是完全公开的执行环境——把 HS256 密钥放进前端等于公开它。前端解码 payload 的正当用途只有展示（用户名、头像、权限标签），真正的鉴权判断必须放在服务端中间件里做完整验证：签名、exp/nbf、aud/iss 是否匹配、以及该 token 是否已被吊销。

5. 常见报错对照表

1. Signature invalid → 密钥不匹配，或有人改动了 header/payload 后没重新签名；先核对 alg 是否被篡改。
2. Token used before issued（或 nbf 未到）→ 签发方与验证方时钟漂移，检查 NTP 与 leeway 配置。
3. JWT malformed → 段数不是三段、分隔符丢失，或 Base64URL padding 被剥离后没有补齐。
4. Suddenly everyone is admin → 检查验证逻辑是否真的校验了签名，而不是只 decode 了 payload。

6. alg=none 攻击：为什么算法白名单是底线

JWT 规范允许 alg 为 none（不签名），早期一批库默认接受它：攻击者把 header 的 alg 改成 none、删掉签名段，验证就静默通过。现代主流库已默认拒绝 none，但只要自己手写解析逻辑，就必须维护算法白名单——从 header 里读 alg 然后照做，等于让攻击者替你选择验证方式。

7. 本页能验什么、不能验什么

解码（读 header/payload）不需要密钥，任何人都能做——这正是 JWT「可自包含展示」的设计。校验签名则不同：本页内置 HS256（以及同族 HMAC）校验，密钥只在你浏览器内存里用一次；RS256/ES256 需要公钥或 JWKS 拉取，属于服务端集成范畴，本页不做。看到「Signature valid」只说明你本地密钥与该 token 匹配，不能代替生产环境的完整校验链（aud/iss、吊销列表、密钥轮换）。

8. 常见 claims 速查（调试时先认这几个）

• sub：主体（常是用户 ID）；不要把邮箱当唯一主键除非业务明确约定。
• iss / aud：签发方与受众——跨服务调用时 aud 不匹配应直接拒绝，而不是「能解出来就算过」。
• jti：令牌唯一 ID，配合服务端黑名单做主动吊销；没有 jti 就很难精确作废单张 token。
• 自定义 claim（role、tenant_id）：只是 JSON 字段，安全语义完全取决于服务端是否校验签名后再信任它们。