开发者工具 · JWT 解码器
JWE 解释：为什么加密的 JWT 有五个部分且没有可读的有效负载
· 背景
jwt 加密 数据格式
有些令牌有四个点而不是两个，并且有效负载不是 JSON。这篇文章解释了 JWE 紧凑序列化、它的五个部分各自包含什么内容，以及为什么没有一个仅解码工具可以显示其声明。
四个点和一个不是 JSON 的有效负载 — 您持有 JWE，而不是 JWS 的标志
四个点和五个段表示与熟悉的三部分签名表格不同的紧凑信封。尝试将其中间字节解析为 JWT 声明会产生无意义的结果，因为内容是密文，而不是明文 JSON 的 base64url 拼写。
ToolAcre 在解码前检查段计数。有五个部分触发 INVALID_JWT 消息，该消息标识 JWE，并解释了为什么此仅解码路由在没有解密密钥的情况下无法显示任何内容。这是一个精确的边界，而不是模糊的解析失败。
五部分——受保护的标头、加密密钥、初始化向量、密文和身份验证标签
紧凑的 JWE 部分表示受保护的标头、加密密钥材料、初始化值、密文和身份验证标记。每个都有独特的加密角色。单独的段位置并不能使第二个或第四个字段成为可读的 JWT 有效负载。
解码器可以分割和 base64url 解码一些字节，但原始字节不能解密。将它们显示为文本会创建替换字符或误导性片段。正确的操作是识别信封并转移到授权的收件人实施。
alg 和 enc — 密钥管理与内容加密，以及为什么 JWE 标头命名两种算法
JWE 标头可以包含用于密钥管理的 `alg` 和用于内容加密的 `enc`。这些标签描述了不同的操作。与签名令牌一样，标头值是必须与接收者策略匹配的输入，而不是令牌选择任意算法的权限。
ToolAcre的三部分算法笔记没有实现JWE处理，五部分分支在头解析之前退出。因此，该页面不显示或认可特定的加密算法。请咨询接收者图书馆和发行者合同以获取支持的选择。
内容加密密钥 — 随机密钥如何保护有效负载以及自身如何为接收者进行包装
内容加密通常使用生成的内容加密密钥，而加密密钥段在接收方安排下传送或导出该密钥。这种分离允许使用内容密码来保护有效负载字节，同时密钥管理策略确定谁可以恢复密钥。
这个概念模型解释了为什么拥有紧凑字符串不足以恢复明文。所需的收件人机密和策略未编码为可免费使用的指令。公共解码器无法发明它们，也不应该要求用户将私有解密密钥粘贴到通用页面中。
当发行人选择 JWE 时 — 必须对客户或中介机构保密的声明
当声明必须对可以看到签名令牌的持有者或中介机构保密时，发行人可以选择加密。这是否是正确的选择取决于威胁模型、密钥分布和操作要求。最小化索赔内容仍然比加密不必要的数据更可取。
加密并不能消除授权、验证或元数据问题。接收者必须验证受保护的内容并在解密后应用令牌策略。授权接收者获得的可读结果并不自动为每项服务所接受。
为什么解码在标头处停止 - 有效负载是密文，因此只有密钥的持有者才能读取它
解码在结构处停止，因为可能的有效负载段是密文。 ToolAcre 故意避免将任意二进制文件显示为 JSON ，而是提供特定消息。这可以防止用户将乱码解释为有效加密信封中的损坏。
如果您是预期接收者，请使用配置了适当密钥和算法的受控软件。如果不是，则不可读的有效负载是预期的安全属性。任何填充技巧或备用字符解码器都无法取代解密。
这不包括什么 - 已签名然后加密的嵌套 JWT，以及 JWE JSON 序列化
嵌套结构可以对内容进行签名，然后对结果进行加密，或者以其他方式在定义的配置文件下组合层。 JWE 还具有超出紧凑的五部分字符串的表示形式。 ToolAcre 不处理这些情况，并且本文不会仅从标头标签推断嵌套。
在故障排除之前记录您的系统需要哪个层。否则，团队可能会尝试对密文进行签名验证或解码未经身份验证的内部令牌。让选定的 JOSE 库在显式策略下处理排序。
要点：解码器只能显示未加密的内容 — ToolAcre JWT 解码器显示签名令牌的标头和有效负载； JWE 的有效负载在设计上是不可读的
解码器只能显示未加密的内容。 ToolAcre 从三部分签名输入的标头和有效负载中读取 JSON，而五个段会导致解释性停止。这种区别可以防止仅解码接口假装具有接收能力。
使用段计数作为路由线索，而不是信任结果。三个可读部分仍需要签名验证；五个加密部分需要授权解密和验证。在这两种情况下，视觉输出本身都不能验证声明或授予访问权限。