JWT 解码器

JWT 解码器到底做什么

一个 JSON Web Token（JWT）看上去像一长串不透明的随机字符，但它并未加密，也不是什么秘密密码。它是一个紧凑、URL 安全的容器，在两方之间携带结构化数据。把一个令牌粘贴进上面的解码器，它就会把那串字符拆开，向你展示里面真正的 JSON — 元数据、声明（claims）、令牌发给谁，以及它何时过期。一切都在你的浏览器里发生。令牌永远不会被上传、记录或发送到任何地方，当你检查的东西是一份活跃的会话凭证时，这一点至关重要。

三个部分，两个点

每一个格式正确的 JWT 都是三段以点连接的 Base64url 编码字符串：header.payload.signature。正是那个点字符让解析器知道一段在哪里结束、下一段从哪里开始，这也是为什么一个点的数量不对的令牌在其他任何内容被读取之前就会被拒绝。

头部（header）是一个描述令牌自身的微小 JSON 对象。它几乎总是包含 typ（类型，通常是 JWT）和 alg — 签名算法，例如 HS256（HMAC 配 SHA-256）或 RS256（RSA 配 SHA-256）。头部准确地告诉验证方签名是如何生成的。

载荷（payload）是大多数人关心的部分。它是另一个 JSON 对象，持有那些声明（claims）— 关于用户和令牌的陈述。规范把声明分为注册声明（标准的、保留的名称）、公共声明，以及私有声明（你为自己的应用发明的自定义名称）。解码载荷揭示的就是谁登录了、他们持有什么角色，以及他们的会话何时失效。

签名（signature）是密码学的封印。它用头部里的算法加上一个密钥或私钥，对编码后的头部和载荷计算得出。由于它覆盖了另外两段，对头部或载荷的任何改动 — 哪怕一个字符 — 都会使它失效。

你最常见到的声明

注册声明是由 RFC 7519 定义的、简短的三字母名称，好让不同系统能互操作。其中少数几个几乎无处不在：

• iss — 签发者（issuer）：谁铸造了这个令牌（你的认证服务器或身份提供方）。
• sub — 主体（subject）：令牌所关于的主体，通常是一个稳定的用户 ID。
• aud — 受众（audience）：令牌意图发给的接收方。一个 API 应当拒绝受众不是自己的令牌。
• exp — 过期时间（expiration time）：一个 Unix 时间戳，过了它令牌就不得再被接受。
• iat — 签发时间（issued at）：令牌被创建时的 Unix 时间戳。

你也可能遇到 nbf（not before，生效时间）和 jti（一个唯一的令牌 ID）。时间戳是 UTC 下自 1970 年起的秒数，这正是为什么一个能把它们渲染成人类可读日期的解码器，帮你省去了核对令牌是否已经过期的心算。

解码不是验证 — 这正是绊倒人的地方

这个区分是理解 JWT 时最重要的一点。解码意味着读取内容：它不需要密钥，任何持有令牌的人都能做到，因为 Base64url 是一种编码，不是加密。验证意味着证明令牌是真实且未被篡改的 — 用正确的密钥或公钥重新计算签名，并确认它匹配。

这个工具做的是解码。它向你展示令牌说了什么，而不是令牌是否可信。一个令牌可能是伪造的、过期的或被重放的，却仍然能解码出看起来完全干净的 JSON。绝不要仅凭解码出的声明做出授权决定。在生产环境中，你要在服务器端验证签名、检查 exp，并确认 iss 和 aud 与你的预期相符 — 使用经过审查的库，绝不手写字符串比较。

载荷不是保险库

由于载荷只是 Base64url 编码的，任何截获令牌的人都能读取它。把里面的一切都当作公开的。不要在 JWT 声明里放置密码、完整的信用卡号、密钥或任何敏感的个人数据 — 如果你在这里一键就能解码它，那么任何拿到副本的人也能。签名防范的是篡改，绝不防范读取。如果你确实需要隐藏载荷内容，那是 JWE（加密令牌）的工作，那是一个完全不同的规范。

隐私与相关工具

检查一个令牌是一项敏感的操作，所以这个解码器完全在客户端运行 — 解析是你标签页里的纯 JavaScript，没有任何东西离开你的机器。把会话令牌粘贴进一个由服务器支撑的工具，等于把一份活跃凭证交给第三方，这恰恰是你应该避免的。关于支撑这一切的底层编码，请看我们的 Base64 工具，并探索我们其余的开发者工具，了解更多在设备本地运行的实用工具。

常见问题