开发者工具 · JWT 解码器
RFC 8725 解释：JWT 验证者当前最佳实践
· 背景
jwt 安全 身份验证
IETF 将已知的 JWT 陷阱收集到一份当前最佳实践文档中。这篇文章将详细介绍其建议，并将每个建议与其所预防的事件类别联系起来。
重复出现的 JWT 失败会激发验证者检查表；存储库来源不建立发布历史
灵活的令牌格式允许验证者必须限制的组合。重复的错误包括信任算法标签、接受错误发行者或受众的令牌以及遵循攻击者选择的密钥材料。检查表将这些广泛的风险转化为实际接受边界的拒绝测试。
大纲将发布历史记录归因于特定年份，但存储库源不验证该历史记录，因此本节省略它。可操作的区别是在本地建立的：ToolAcre 仅解码，而每个最佳实践决策都属于配置的验证者。
固定算法并拒绝任何算法 - 解决 alg:none 和密钥混淆问题的建议
独立于标头固定允许的算法，并拒绝需要签名的流中的未签名输入。将每个接受的算法系列绑定到正确的密钥类型。不要让令牌将验证程序从非对称检查切换到 HMAC 或使用 `none` 禁用检查。
ToolAcre 标记 `none` 并解释识别的标签，但这些警告不执行任何操作。通过针对后端的负面测试来证明真实策略：意外的算法、空签名和错误的密钥类型必须失败，即使它们的前两个段仍然可解码。
验证受众和发行者 - 针对跨服务重放的建议
在可信密钥配置下对颁发者进行身份验证，然后将目标受众与消费服务进行比较。没有上下文声明检查的有效签名仍然可以在错误的位置授权令牌。复制的颁发者字符串本身不是键绑定。
解码器在不知道预期配置的情况下显示 `iss` 和 `aud` 值。使用这种可见性来识别测试用例，而不是做出结论。验收测试应区分错误的发行者、错误的受众和签名失败，以便操作日志仍然有用。
使用显式类型——类型标头作为对标记替换的防御
显式标记类型可以分隔配置文件，否则会重用类似的声明形状。验证者应该知道它期望特定端点的类型并拒绝不兼容的配置文件，而不是将每个签名的 JWT 视为可互换的。
`typ` 标头在验证之前仍然不受信任，ToolAcre 仅在其字符串与 `JWT` 不同时发出警告。它不验证访问令牌配置文件、嵌套内容或提供者约定。在应用程序中定义类型规则并测试替换尝试。
不要信任 jku、x5u 或嵌入式密钥 - 密钥源建议
不要让 `jku`、`x5u`、嵌入式 JWK 数据或证书数组仅仅因为它们出现在受保护的标头中而建立密钥源。通过独立可信的颁发者关系和受约束的检索策略来解析密钥。仅将 `kid` 视为该边界内的选择器。
ToolAcre 不根据标头值执行网络查找。这是普通检查员的正确行为。在审核期间，跟踪从标头元数据到文件系统、缓存、数据库和网络操作的每条路径，然后拒绝从令牌控制的输入创建信任的任何路径。
必须在所选库和配置文件中检查加密输入和加密内容指南
加密实现必须验证输入并遵循所选配置文件的规则。加密设计还需要注意压缩和可观察数据。确切的 API 和默认值是特定于库的，并且不存在于此存储库中，因此本文不会发明开关或声称通用支持。
阅读已部署库和版本的当前文档，然后构建格式错误的输入和策略不匹配的测试。解码器的干净 INVALID_JWT 错误证明了良好的检查人体工程学，但它们并不能证明单独的验证器可以正确处理加密边缘情况。
工作示例 — 根据清单审核验证例程
通过列出受信任的发行者配置、接受的算法、密钥来源、受众、令牌类型、时间策略和应用程序声明来审核验证例程。对于每一项，添加一个语法上可读但完全违反一个期望的否定标记。确认真实边界处的拒绝。
仅使用 ToolAcre 检查每个夹具声明的内容并确保存在预期的突变。不要使用其输出作为夹具无效的断言。验证者的响应和日志提供了证据，而解码器在接受和拒绝的示例中保持不变。
要点：检查表，而不是库 — ToolAcre JWT 解码器可帮助您在审核期间检查令牌；这些做法适用于您编写的验证程序
最佳实践文档是检查表，而不是验证库。当团队将建议转化为显式配置、狭窄的信任关系和失败的测试时，它的价值就显现出来了。解码器可以在该工作期间使令牌输入清晰，但无法实现控制。
维护文档和 UI 中的边界：解码意味着可读、不真实、未经修改、授权或可接受。将策略固定在令牌之外，首先验证，然后应用声明。 ToolAcre 有意在所有这些决定之前停止。