JWT Decoder

什么是 JWT？

JSON Web Token（JWT，读作 "jot"）是 RFC 7519 定义的紧凑、签名 JSON 对象。它在两方之间传递 Claims，典型场景是 Auth 服务器与 API 之间。服务器在认证成功后签发 token，客户端在每次 API 调用时通过 `Authorization: Bearer ...` 头携带。

JWT 由三段以点连接的 base64url 编码部分构成。它不是加密，仅是签名。任何拿到 token 的人都能读取内容，因此密码或其他机密绝不能放入 payload。

相对服务端 Session 的优势：JWT 是自包含的。API 服务器无需联系 Auth 服务器或查询 Session 库即可验证 token 并提取权限。横向扩展非常出色，但代价是难以提前撤销单个 token。

Header、Payload、Signature 解读

每个 JWT 都由三部分组成，以单个点连接：

• Header：小型 JSON 对象，含 `alg`（算法，例如 HS256、RS256、ES256）和 `typ`（通常为 "JWT"）。有时还含 `kid`（密钥 ID），提示用了哪把签名密钥。
• Payload：JSON 对象，承载 Claims。标准字段有 `iss`（颁发者）、`sub`（Subject）、`aud`（Audience）、`exp`（过期）、`nbf`（生效时间）、`iat`（签发时间）和 `jti`（唯一 Token ID）。也允许自定义字段。
• Signature：以 `base64url(header) + "." + base64url(payload)` 为输入，按所配算法计算。它保护完整性：未掌握密钥就无法在不被发现的情况下篡改内容。

重要：base64url 是编码，不是加密。Header 和 Payload 任何观察者都能阅读。

JWT 与 Session Cookie

两种方案都保留认证状态，但路数不同：

• Session Cookie：不透明 ID，服务器据此在 Session 库中查找完整状态。可即时撤销，但每次请求都要查一次。
• JWT：状态本身嵌在 token 中，仅靠签名保护。无需查找，非常适合微服务架构，但要在过期前撤销则需要 allow/deny 列表。
• 大小：JWT 通常 300 至 1500 字节；Session ID 大约 32 字节。在大量 API 调用时 JWT 体积在带宽上会累积。
• 存储：在浏览器世界，Cookie（HttpOnly、Secure、SameSite）是更安全的存储位置。localStorage 暴露给 XSS。

经验法则：纯服务端应用用 Session；API 网关与移动后端用 JWT，理想是短生命周期 + Refresh Token 流程。

JWT 安全：如何对待 `algorithm: none`？

近些年 JWT 库出过几起轰动 bug。最大的几个陷阱：

• `alg: none`：曾有库在 Header 声明 "none" 时接受未签名 token。修复：永不允许 `none`，在服务器侧硬编码允许的算法。
• HS256/RS256 混淆：攻击者用 RSA 公钥作为 HMAC Secret 签发 token，服务器把它当 HS256（而非 RS256）校验，遂被骗过。防御：在服务器侧固定允许的 `alg`。
• `kid` 注入：`kid` 字段指向某个密钥，但若未消毒会导致路径遍历或 SQL 注入。把它当作不可信输入处理。
• 弱 Secret：用 "secret" 或 "password" 作为 HS256 密钥的 token 几秒内即可被暴破。请使用至少 256 位随机字节，最好来自 `crypto.getRandomValues()` 或 `/dev/urandom`。
• 生命周期过长：每个签发出去的 JWT 直到过期都有效，即便用户已 "登出"。请用短生命周期（15 分钟）+ Refresh Token，或对敏感端点维护 Deny 列表。

OWASP 速查表系列与 RFC 8725（JWT Best Current Practices）是必读。

如何校验一个 JWT？

完整校验远不只是签名。服务器代码中的顺序：

• 解析 Header，把 `alg` 与白名单对比（例如仅允许 RS256）。
• 用与 Issuer 配置匹配的密钥校验签名。使用 JWKS 时可用 `kid` 作为查找键，但要先白名单其值。
• 校验标准 Claims：`iss` 等于预期颁发者，`aud` 包含自身 Audience，`exp` 在未来，`nbf` 与 `iat` 在过去（容许少量时钟偏差）。
• 按业务模型校验自定义 Claims（角色、租户 ID、Scopes）。
• 如需提前撤销，检查 Deny / Logout 列表。

请依靠成熟库（jose、jjwt、jsonwebtoken 等），而不是自己写。密码学不是手工活儿。

在 KernelHost 托管你的 Auth 后端

JWT Issuer 与 Resource Server 需要可靠、低延迟的后端。KernelHost 在 Frankfurt FRA01 自营 VPS 与独立服务器，含 DDoS 防护、IPv4 + IPv6 与 1 Gbit/s 上行链路。对欧洲用户的低 RTT、价格合理、无供应商锁定。公司位于 Wien（AT），数据中心在 Frankfurt（DE）。

JWT 常见问题