在 authentication_code 流程中使用时，id_token 是否应该包含声明答案

【问题标题】：Should id_token contain claims when used during authorization_code flow在 authentication_code 流程中使用时，id_token 是否应该包含声明
【发布时间】：2018-11-17 07:52:01
【问题描述】：

使用response_type=code 和scope=openid email 对支持OpenID 的OAuth2 授权服务器进行身份验证后，调用令牌端点应返回id_token。

我缺少的是这个id_token 是否应该包含email - 在这种情况下客户端应该调用userInfo 端点。

规范说：

http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims

配置文件、电子邮件、地址和电话范围值请求的声明从 UserInfo 端点返回，如第 5.3.2 节所述，当使用导致访问令牌被发布的 response_type 值时。但是，当没有颁发 Access Token 时（response_type 值 id_token 就是这种情况），生成的 Claims 会在 ID Token 中返回。

据我了解，这意味着如果access_token 可用，则id_token 不需要包含email，因为应该调用userInfo 来获取它。然而，看看https://github.com/bitly/oauth2_proxy 中oidc 客户端的实现，似乎他们确实需要email 声明在id_token 中可用，而无需调用userInfo 端点。

OpenID 兼容授权服务器中的正确行为是什么？

【问题讨论】：

我猜配置文件范围（声明）将定义要包含在 id_token 中的内容，资源范围（给定声明映射）定义要包含在 access_token 中的内容

标签： email oauth-2.0 openid claims userinfo

【解决方案1】：

openid 规范比 Google 或 Microsoft 正在做的更严格（可能其他提供商也是如此，但我没有检查）。我猜 oauth2_proxy 保留了提供者的行为。例如，在将 code 交换为 access_token 时，Google 会返回 id_token 以及您请求的范围内的所有声明。但是，如果您阅读他们的文档，他们确实会指定 userInfo 端点： https://developers.google.com/identity/protocols/OpenIDConnect

我认为，只要您支持所有端点，是否返回 id_token 以及所有声明以及 access_token 取决于您。在大多数情况下，它消除了对 userInfo 的一个额外调用，并且不会暴露任何漏洞。

【讨论】：

【解决方案2】：

另见https://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter

如果不存在，则根据Section 2 中的 ID 令牌定义以及 3.1.3.6、3.2.2.10、3.3.2.11 和3.3.3.6.

使用response_type=code 时，适用第 2 节和第 3.1.3.6 节。

ID 令牌的内容如第 2 节所述。使用授权代码流程时，以下 ID 令牌声明的这些附加要求适用： at_hash: […]

因此，作为 OpenID Connect 1.0 客户端，除了第 2 节和at_hash 中定义的声明之外，您不应期望 ID 令牌中出现其他声明。我不相信 OpenID Connect 1.0 禁止 ID 令牌中的其他声明（例如来自用户的个人资料），但通用客户端不应依赖它们的存在。

这意味着 oauth2_proxy 不是一个通用客户端，因为它依赖于特定提供商的实现。

【讨论】：

【解决方案3】：

OpenID Connect Core 表示 id_token 可能包含其他声明。在 SAML 断言中，属性也是可选的。一些 SaaS 提供商可能会反对 Userinfo API 调用（即 SAML 中的工件）。在 Gluu 服务器中，我们有一个用于 legacyIdTokenClaims 的服务器级 JSON 配置选项。默认情况下禁用此功能 - 在令牌端点呈现代码 + client_creds 更利于安全。如果设置为 true，Gluu 服务器将包含与为客户端指定的 OpenID 范围相对应的声明。

【讨论】：