在OpenID Connect spec中，azp（授权方）声称似乎有矛盾。
在ID令牌定义部分2中，它说：
AZP
可选的。授权方 - 签发ID令牌的一方。如果存在，它必须包含该方的OAuth 2.0客户端ID。 仅当ID令牌具有单个受众值并且受众与授权方不同时，才需要此声明。即使授权方与唯一的受众相同，也可以包含它......
但在令牌验证部分3.1.3.7中，其中一个步骤似乎恰恰相反：
- 如果ID令牌包含多个受众群体，则客户端应该验证是否存在azp声明。
有人能否解释这种明显的差异？只有第二个实例使用了声明性语言，所以我倾向于在我的实现中支持它。
答案 0 :(得分：5)
您是正确的，OIDC中的整个azp情况令人困惑。对于它的价值，他们有一个与之相关的未决问题;见OIDC - Issue 973 (azp claim underspecified and overreaching)。
来自＆＃34; aud＆＃34;的定义在JWT及其在Connect的ID令牌中的使用（相关规范文本在下面复制），似乎客户端/ RP的客户端ID必须是其中一个值，或者是唯一的价值，＆＃34; aud＆＃34;在ID令牌中声明。这是合乎逻辑且一致的，并为实施者提供有关生成和使用ID令牌的可靠且可互操作的指导。我认为发出身份验证请求的RP /客户端的客户端ID应始终在返回的ID令牌的aud中表示。
围绕＆＃34; azp＆＃34;的文字然而，在ID令牌部分和ID令牌验证部分似乎可能会提出不同的建议。或许，在某些完全未指定的情况下，发出身份验证请求的RP /客户端的客户端ID可能是azp声明的值，并且aud不会将该客户端标识为预期的收件人。我是否误解了事情？
就个人而言，从客户端应用程序开发人员的角度来看，最佳行动方案似乎是遵守ID令牌验证规则，这些规则始终暗示azp中的值也将作为aud出现。但是，根据谷歌在线提供的内容有点不同，所以azp中的值aud未列在azp中，因此可能会出现在Google上玩的情况规则而非（仅）OIDC。
如果您正在实施OP，那么可能不错的选择也是在可能的情况下完全避免将azp包括在您的已发行代币中，或者仅在使用多个受众时将其包含在其中，其中一个是值也在// With Stylus preprocessor:
$gutter = 1.5rem
$sizeXS = 36.01rem
.masonry
margin $gutter 0
column-gap $gutter
@media (min-width $sizeXS)
.masonry
column-count 2
// etc...
。
答案 1 :(得分：0)
我认为这两个部分在概念层面上并没有相互冲突（虽然措辞有点混乱）。
如果有一个观众与 azp 不同，那么让 azp 和观众都表现出这种差异是有意义的。在多观众情况下，至少有一个观众会与 azp 不同，因此 azp 必须在场才能清楚。
azp 通常等于客户端 ID（应用程序请求令牌）。令牌的受众可以是应用本身，也可以是接收令牌进行验证的其他应用。