开发者工具 · JWT 解码器

解码与验证：JWT 签名证明了什么以及解码器为何跳过它

2026年7月21日 · 工作原理

jwt 安全密码学

解码无需密钥；验证需要正确的。这篇文章解释了签名涵盖的内容、HMAC 和非对称验证有何不同，以及为什么仅解码工具诚实地不证明任何内容。

它解码得很好，所以它一定是有效的——导致接受伪造令牌的假设

在攻击者写入新的有效负载并附加任意文本作为第三段后，令牌可以完美解码。 Base64url 和 JSON 解析是公共转换；两者都不检查谁组装了字符串。因此，“屏幕上出现的索赔”并不能证明发行人创建或批准了这些索赔。

ToolAcre 在多个地方强化了这一边界。结果始终带有 `signatureVerified: false`，UI 在输出旁边重复未验证的声明警报，并测试断言不存在 `valid` 或 `verify` 表面。这是刻意的诚实，而不是缺失的便利功能。

对于紧凑型 JWS，签名输入是编码的受保护标头段、文字点和编码的有效负载段。验证涉及那些确切的编码字节，而不是新打印的漂亮的 JSON。即使人类看到相同的对象，重新排序属性或更改空白也可能会创建不同的字节。

第三段携带通过该输入生成的编码签名或 MAC 字节。 ToolAcre 保留原始段并可能报告其字节长度，但它从不运行加密检查。测量数据形状无法确定预期的密钥创建了它，或者前两个段保持不变。

使用 HMAC，共享密钥支持创建和检查 MAC。能够验证该秘密的一方也可以铸造另一个令牌，因此秘密分发定义了信任边界。 ToolAcre 的注释对其公认的 HS 算法标签明确说明了这一结果。

非对称签名将私人签名功能与公共验证材料分开。拥有公钥可以支持检查而无需授予签名权限。这种区别并不会使标头声明的非对称标签值得信赖：验证者必须已经知道哪种算法和颁发者密钥是可接受的。

共享机密应来自受保护的服务配置，而不是令牌文本。公共验证密钥可以来自受信任的发行者关系和受控密钥集。 `kid` 可以帮助在该集合中进行选择，但它不得将任意不受信任的标头内容转换为文件、数据库或网络查找。

ToolAcre 没有颁发者配置并且不请求密钥，因此不可能在那里负责任地执行验证。通用网页无法推断您信任哪个组织、您服务的受众或您的应用程序允许哪些算法。这些是应用程序策略输入，而不是可通过解码发现的属性。

解码不需要密钥，因为 base64url 是可逆编码而不是加密。标头和有效负载旨在与令牌一起传输，并且可以由任何持有者恢复。这可以实现有用的检查，但也意味着机密信息不应隐藏在编码字符的视觉噪声后面。

JSON 解析仅添加结构。它可以告诉您 `roles` 是一个数组或 `exp` 是一个数字，但并不是说这两个值都是真实的。 ToolAcre 将结构化值呈现为文本，将注册描述呈现为文档，同时将授权留给可以验证和执行策略的系统。

从一个合成令牌开始，其有效负载为 `{"sub":"demo","role":"reader"}`。更改一个编码的有效负载字符，以便字节仍然形成有效的 JSON，也许会产生不同的角色。两个版本都可以分割、解码和漂亮打印。解码路径没有理由拒绝更改的版本。

正确配置的验证程序根据更改的签名输入重新计算或检查加密结果并拒绝不匹配。这种比较展示了精确的边界：解码器成功涵盖了语法，而验证者成功可以在评估声明策略之前建立相对于可信密钥和允许算法的完整性。

ToolAcre 从不验证签名。空段收到警告，格式错误的签名编码收到另一个警告，可测量字节被报告为存在但未经验证。这些分支都不会产生真正的令牌判决。该实现没有隐藏的密钥获取或算法执行路径。

即使成功的密码验证也不会自动授权操作。消费服务仍然需要发行者、受众、时间和特定于应用程序的检查。本文在库配置之前停止，因为支持和默认值各不相同；请咨询您的服务使用的确切验证程序和版本。

在信任之前进行解码以检查和验证。当您需要查看标头字段、有效负载值、时间转换和结构警告时，请使用过期或合成令牌的浏览器工具。切勿让可读输出直接影响访问决策。

将后续工作转移给具有独立提供的密钥材料、固定算法和服务策略的可信验证者。只有该路径才能测试真实性和完整性，并且只有后续的声明检查才能决定授权。解码器拒绝模糊这些工作是一项安全功能。