开发者工具 · JWT 解码器
受众和发行者检查：阻止 JWT 在其他地方重播
· 为什么它很重要
jwt 身份验证 安全
为一项服务发行的令牌可以提供给共享同一发行者的另一项服务。这篇文章解释了 aud 和 iss 检查如何阻止这种情况，以及如何读取令牌中的两个声明。
服务 B 接受服务 A 的令牌 — 有效签名不会阻止跨服务重放
签名对于颁发给不同服务的令牌可能有效。如果多个 API 信任相同的身份平台但忽略接收者上下文，则用于服务 A 的凭证可能会在服务 B 上重放。密码完整性本身并不能回答谁应该使用它。
ToolAcre 可以显示 `iss` 和 `aud`，以便开发人员可以发现明显的不匹配。在签名成功之前，这些字符串将保持未验证状态，并且浏览器工具永远不会执行该检查。实际的资源服务器必须强制执行其发布者关系和目标受众。
iss — 将令牌绑定到您的服务信任的颁发者，以及为什么在没有密钥绑定的情况下字符串匹配是不够的
`iss` 标识有效负载声明颁发令牌的实体。验证者需要在其自己的配置下有一个确切的预期发行者，并且必须将该身份绑定到正确的密钥发现关系。比较没有加密绑定的文本为攻击者复制预期字符串留下了空间。
解码器将 `iss` 描述为“谁创建了令牌”，但这是注册的含义，而不是关于粘贴值的发现。可读的发行者文本是调试配置的有用证据。它无法选择任意密钥源或对自身进行身份验证。
aud — 命名预期接收者的字符串或数组，以及验证者必须在其中找到自己的规则
`aud` 命名预期收件人，可能显示为一个字符串或一个集合。资源服务器的策略必须使用其配置文件所需的精确比较规则在经过身份验证的值中找到自己。它不应仅仅因为列出了其他一些熟悉的服务而接受令牌。
ToolAcre 在其声明表中将数组作为 JSON 文本，保留其可见结构以供检查。它不知道当前 API 的标识符，无法决定匹配。这种故意的缺席阻止了通用解码器发明它不拥有的授权上下文。
azp 和范围 — OpenID Connect 和 OAuth 声明，细化了谁可以使用令牌以及用途
`azp` 和 `scope` 可以在定义它们的配置文件中添加有关授权方和请求权限的上下文。它们不会取代受众、发行者或签名检查。在资源服务器将经过身份验证的值映射到其自己的策略之前，范围名称是一个断言，而不是权限授予。
当前解码器将这些视为特定于应用程序的声明，因为其注册描述表涵盖了七个核心名称。它显示它们的值，但不提供 OpenID Connect 或 OAuth 语义。在做出决定之前，请先查阅适用的配置文件和提供商合同。
混淆代理模式 — 当受众未经检查时，合法令牌如何成为攻击
困惑的代表在意想不到的情况下使用合法权力。即使没有人伪造签名，错误服务接受的令牌也可能准确触发该模式。受众检查限制了可以应用经过身份验证的声明的位置，而发行者检查则限制了服务考虑的断言。
这就是为什么一般的“签名有效”标志仍然不够。授权取决于接收者和操作。 ToolAcre 通过不报告验证结果来完全避免这种歧义，让消费服务将加密与上下文策略结合起来。
工作示例 — 从 ToolAcre JWT 解码器中的两个令牌读取 iss 和 aud，并决定哪个服务应接受每个令牌
创建两个无害的令牌，其解码的有效负载仅在 `aud` 上有所不同：一个名称为 `service-a`，另一个名称为 `service-b`；两者都声称是同一发行人。 ToolAcre 使差异显而易见。服务 A 验证者不仅不应接受来自此显示的内容，而且应拒绝经过身份验证的服务 B 受众。
然后用两个颁发者字符串反转练习。除非使用该发行者信任的密钥进行验证，否则仅预期文本是不够的。这些示例将检查与接受分开，并说明了为什么将看似正确的声明复制到伪造的令牌中不会改变可信策略。
这不包括签名验证，解码器从不执行； aud 和 iss 检查仅在签名生效后才起作用
只有在加密验证确定受保护的字节对应于可信密钥材料之后，受众和发行者检查才有意义。 ToolAcre 不执行任何验证。其输出无法确定索赔完好无损或由已知发行人撰写。
它也不会获取元数据、选择密钥或比较配置的收件人。使用后端测试和日志来证明对错误发行者和错误受众的拒绝。解码器中的视觉匹配是调试线索，而不是足够的授权证据。
要点：检查它的用途，而不仅仅是签名者 — ToolAcre JWT 解码器显示您需要比较的 aud 和 iss 声明
检查令牌是谁的，而不仅仅是它所说的签名名称。强大的流程在独立可信的发行者关系下对受保护的字节进行身份验证，然后需要可接受的受众并应用特定于服务的授权规则。
使用 ToolAcre 读取安全测试值并制定下一个服务器端检查。不要从不受信任的标头或声明数据中选择验证密钥，也不要在没有完全可信流程的情况下将显示的 `iss`、`aud`、`azp` 或 `scope` 转换为授权。