OpenID Connect 标准：授权方 azp 矛盾
OpenID Connect Standard: Authorized Party azp Contradiction
在OpenID Connect spec中azp（授权方）的说法似乎有矛盾。
在 ID 令牌定义部分 2 它说：
azp
OPTIONAL. Authorized party - the party to which the ID Token was issued. If present, it MUST contain the OAuth 2.0 Client ID of this party. This Claim is only needed when the ID Token has a single audience value and that audience is different than the authorized party. It MAY be included even when the authorized party is the same as the sole audience...
但在令牌验证部分 3.1.3.7，其中一个步骤似乎是相反的：
- If the ID Token contains multiple audiences, the Client SHOULD verify that an azp Claim is present.
任何人都可以阐明这种明显的差异吗？只有第二个实例使用声明性语言，所以我倾向于在我的实现中支持它。
你是对的，OIDC 中的整个 azp 情况令人困惑。对于它的价值，他们有一个与之相关的悬而未决的问题；参见 OIDC - Issue 973 (azp claim underspecified and overreaching)。
From the definition of "aud" in JWT and its use in Connect's ID Token (relevant spec text is copied below), it seems that that the client id of the client/RP that made the authentication request has to be one of the values, or the only value, of the "aud" claim in the ID Token. That's logical and consistent and provides reliable and interoperable guidance to implementers about producing and consuming the ID Token. I think that the client id of the RP/client that made the authentication request should always be represented in the aud of the returned ID Token.
The text around "azp" in the ID Token section and the ID Token Validation section seems to maybe suggest something different, however. Like perhaps that the client id of the RP/client that made the authentication request could, in some totally unspecified circumstance, be the value of the azp claim and that the aud would not identify that client as an intended recipient. Am I misinterpreting things?
就个人而言，从客户端应用程序开发人员的角度来看，最好的做法似乎是遵守 ID 令牌验证规则，该规则始终意味着 azp 内的值也将作为 aud.然而，根据在线可用的内容，Google 似乎使用它有点不同，所以你可以在 azp 中获得一个未在 aud 中列出的值，因此可能存在你玩 aud 的情况=25=] 规则而不是（仅）OIDC。
如果您正在实施 OP，一个可能不错的选择是完全避免在您发行的令牌中包含 azp，或者仅在使用多个受众时才包含它，其中一个是价值也在 azp.
我认为这两个部分在概念层面上并不相互冲突（虽然在措辞上有点混乱）。
如果只有一个受众与 azp 不同，那么同时拥有 azp 和受众以显示这种差异是有意义的。在多受众的情况下，至少有一个受众与 azp 不同，因此必须存在 azp 以使其清楚。
azp 通常等于client id（应用程序请求token）。令牌的受众可以是应用程序本身或接收令牌进行验证的另一个应用程序。
在OpenID Connect spec中azp（授权方）的说法似乎有矛盾。
在 ID 令牌定义部分 2 它说：
azp
OPTIONAL. Authorized party - the party to which the ID Token was issued. If present, it MUST contain the OAuth 2.0 Client ID of this party. This Claim is only needed when the ID Token has a single audience value and that audience is different than the authorized party. It MAY be included even when the authorized party is the same as the sole audience...
但在令牌验证部分 3.1.3.7，其中一个步骤似乎是相反的：
- If the ID Token contains multiple audiences, the Client SHOULD verify that an azp Claim is present.
任何人都可以阐明这种明显的差异吗？只有第二个实例使用声明性语言，所以我倾向于在我的实现中支持它。
你是对的，OIDC 中的整个 azp 情况令人困惑。对于它的价值，他们有一个与之相关的悬而未决的问题；参见 OIDC - Issue 973 (azp claim underspecified and overreaching)。
From the definition of "aud" in JWT and its use in Connect's ID Token (relevant spec text is copied below), it seems that that the client id of the client/RP that made the authentication request has to be one of the values, or the only value, of the "aud" claim in the ID Token. That's logical and consistent and provides reliable and interoperable guidance to implementers about producing and consuming the ID Token. I think that the client id of the RP/client that made the authentication request should always be represented in the aud of the returned ID Token.
The text around "azp" in the ID Token section and the ID Token Validation section seems to maybe suggest something different, however. Like perhaps that the client id of the RP/client that made the authentication request could, in some totally unspecified circumstance, be the value of the azp claim and that the aud would not identify that client as an intended recipient. Am I misinterpreting things?
就个人而言，从客户端应用程序开发人员的角度来看，最好的做法似乎是遵守 ID 令牌验证规则，该规则始终意味着 azp 内的值也将作为 aud.然而，根据在线可用的内容，Google 似乎使用它有点不同，所以你可以在 azp 中获得一个未在 aud 中列出的值，因此可能存在你玩 aud 的情况=25=] 规则而不是（仅）OIDC。
如果您正在实施 OP，一个可能不错的选择是完全避免在您发行的令牌中包含 azp，或者仅在使用多个受众时才包含它，其中一个是价值也在 azp.
我认为这两个部分在概念层面上并不相互冲突（虽然在措辞上有点混乱）。
如果只有一个受众与 azp 不同，那么同时拥有 azp 和受众以显示这种差异是有意义的。在多受众的情况下，至少有一个受众与 azp 不同，因此必须存在 azp 以使其清楚。
azp 通常等于client id（应用程序请求token）。令牌的受众可以是应用程序本身或接收令牌进行验证的另一个应用程序。