在OpenID Connect spec 中，azp（授权方）的说法似乎有矛盾。
在 ID 令牌定义部分 2 它说：
azp
可选。授权方 - 向其颁发 ID 令牌的一方。如果存在，它必须包含该方的 OAuth 2.0 客户端 ID。 仅当 ID 令牌具有单一受众值并且该受众不同于授权方时，才需要此声明。即使授权方与唯一受众相同，也可能包含在内...
但在令牌验证部分3.1.3.7，其中一个步骤似乎相反：
- 如果 ID 令牌包含多个受众，客户端应验证 azp 声明是否存在。
有人能解释一下这种明显的差异吗？只有第二个实例使用声明性语言，所以我倾向于在我的实现中使用它。
【问题讨论】：
标签： jwt openid-connect
您是对的，OIDC 中的整个azp 情况令人困惑。对于它的价值，他们有一个与之相关的未解决问题；见OIDC - Issue 973 (azp claim underspecified and overreaching)。
从 JWT 中“aud”的定义及其在 Connect 的 ID 令牌中的使用（相关规范文本复制如下），似乎发出身份验证请求的客户端/RP 的客户端 ID 必须是ID 令牌中“aud”声明的值或唯一值。这是合乎逻辑且一致的，并为实施者提供了有关生成和使用 ID 令牌的可靠和可互操作的指导。我认为发出身份验证请求的 RP/客户端的客户端 ID 应始终以返回的 ID 令牌的 aud 表示。
但是，ID 令牌部分和 ID 令牌验证部分中围绕“azp”的文本似乎暗示了一些不同的东西。就像发出身份验证请求的 RP/客户端的客户端 ID 在某些完全未指定的情况下可能是 azp 声明的值，并且 aud 不会将该客户端标识为预期的接收者。我是否误解了一些事情？
就个人而言，从客户端应用程序开发人员的角度来看，最好的做法似乎是遵守 ID 令牌验证规则，该规则始终暗示 azp 中的值也将作为 aud 出现。但是，根据在线可用的内容，Google 似乎对它的使用有所不同，因此您可能在azp 中的值未在aud 中列出，因此可能存在您按 Google 规则而非（仅）OIDC 玩的情况。
如果您正在实施一个 OP，一个可能的好选择是完全避免在您已发行的令牌中包含 azp（如果可能），或者仅在使用多个受众时才包含它，其中一个受众也是 @ 中的值987654328@.
【讨论】：
我认为这两个部分在概念层面上并不冲突（虽然措辞有点混乱）。
如果有一个单一的受众与 azp 不同，那么同时拥有 azp 和受众来显示这种差异是有意义的。在多个受众的情况下，至少有一个受众与 azp 不同，因此 azp 必须在场才能明确。
azp 通常等于客户端 ID（应用程序请求令牌）。令牌的受众可以是应用本身，也可以是接收令牌进行验证的其他应用。
【讨论】：