开发者工具 · JWT 解码器

RFC 7519 和 JOSE 系列：JWT、JWS、JWE、JWK 和 JWA 解释

2026年1月21日 · 背景

jwt 密码学标准

JWT 是 IETF JOSE 工作组规范系列的成员之一。这篇文章解释了每个 RFC 的定义、它们如何组合在一起，以及为什么 JWT 通常是 JWS。

五个首字母缩略词，一个标记 — 为什么当您只询问 JWT 时文档会提到 JWS 和 JWE

令牌文档在 JWT、JWS、JWE、JWK 和 JWA 之间移动，因为它们描述了同一生态系统的不同层。当“JWT”被用作每个紧凑的三部分签名令牌的简写时，混乱就开始了。将声明与信封和密钥表示分离使得实现更容易推理。

ToolAcre 的解码器故意比该系列更窄。它处理三部分 JWS 形状的输入，其前两个解码段是 JSON 对象。它检测到五部分加密的紧凑输入并停止，因为在没有接收者密钥的情况下读取密文不会解码相同的内容。

相关规范来自 IETF JOSE 工作，但存储库来源并未建立大纲要求的详细组织时间表。因此，本文避免发明日期或流程历史记录，而是集中讨论工具和计划中可观察到的格式关系。

实际问题是哪一层拥有每个决策。声明名称描述应用程序语句，签名保护编码材料，加密保护内容，JSON 密钥对象表示密钥信息，算法标识符名称操作。没有一个缩写词可以取代其他缩写词。

JWS 描述签名或受 MAC 保护的内容。其紧凑形式由三部分组成：受保护的标头、有效负载和签名。签名输入使用由点连接的前两个编码段。 JWT 通常在此信封中传输，这是 ToolAcre 分割和检查的形式。

标头和有效负载可以解码为 JSON，而签名是字节而不是第三个对象。 ToolAcre 报告签名的存在和大小，但始终将其标记为未经验证。因此它可以说明 JWS 结构而无需声明任何加密结果。

JWE 描述加密内容。它的紧凑形式有五个部分，分别代表受保护的标头、加密密钥材料、初始化值、密文和身份验证标签。因此，四个点是一个强有力的结构线索，表明由三部分组成的 JWT 解码器已收到不同的包络。

ToolAcre 发出特定的 JWE 错误，并解释说没有解密密钥就无法读取内容。它不会将密文视为格式错误的 JSON 或尝试显示随机字节。加密和签名也可以组合，但嵌套处理不在此路线之外。

JWK 为加密密钥信息提供 JSON 表示，而 JWA 命名算法标识符和 JOSE 中使用的相关参数。它们的存在并不意味着令牌可以选择自己的可信密钥或算法。验证者必须受到发行者和应用程序策略的约束。

ToolAcre 算法注释仅解释源中存在的有限标签集，并调用任何其他无法识别的标签。它们是描述，而不是实现。解码器既不导入 JWK，也不执行来自 JWA 的算法，这使检查边界保持明确。

JWT 定义声明对象和注册名称，例如颁发者、主题、受众和 NumericDates。这些声明可以以签名或加密的 JOSE 结构来承载。因此，有效负载层回答“表示什么语句”，而信封回答如何保护或隐藏这些字节。

ToolAcre 期望解码后的有效负载是 JSON 对象并列出其声明。此工具拒绝数组、数字或空值。即使形状良好的对象也仍然不受信任，直到相关信封被配置的验证者或接收者处理为止。

后来的最佳实践和概况文档可以缩小这些通用机制的使用方式。它们应该单独对待，因为基本格式不提供特定于应用程序的发行者、受众或令牌类型策略。本文并不声称解码器实现任何此类配置文件。

在审查系统时，写下确切的配置文件、预期的范围、可接受的算法、关键来源和声明规则。该列表可以防止缩写词熟悉变成兼容性或安全性的假设。

JWT 命名声明层； JWS和JWE提供保护外壳； JWK代表关键数据； JWA 命名算法选择。 ToolAcre 读取常见的三部分签名形状并显示标头和声明，同时拒绝验证或解密。

使用该地图提出下一个问题。可读 JSON 标识声明层。三到五个部分可识别可能的信封系列。信任仍然依赖于独立配置的密码学和策略，而不是依赖于识别首字母缩略词的解码器。