在 OpenID Connect 中，当“代码”流更安全地执行相同的操作时，“代码 id_token”混合工作流的目的是什么？

Question

在学习使用 OpenID Connect/OAuth2 的 ASP.NET 身份安全课程时，我了解了不同工作流程的差异和优缺点。

具体来说，我对混合工作流程的目的感到困惑code id_token，它就像授权代码工作流程一样，只不过它还id_token从前通道返回（简化的）。

所以我的第一个问题是id_token，如果稍后要通过反向通道再次检索完整的 id 令牌和访问令牌，那么首先由第一个（不太安全的）请求返回淡化的目的是什么？

另一件事是关于安全性：课程讲师提到，code id_token即使没有 PKCE 保护，混合工作流程也被认为是安全的，原因有两个：

1. 初始值id_token包含一个c_hash将其与授权代码关联的值，以保护其免受授权代码泄漏/重放攻击

我的问题：由于这个首字母id_token以完全相同的方式与授权代码一起返回，如果授权代码被泄露，我们是否应该假设它id_token也被泄露，从而使这种保护无效？

2. 该nonce字符串确保授权码一次性使用

我的问题：由于nonce是以纯文本形式包含在 URL 中，如果攻击者设法在合法用户之前将重定向响应连同授权代码一起发布到客户端，那么攻击就会成功，对吗？

鉴于这些，是否可以说具有 PKCE 保护（加上随机数）的授权代码工作流程比code id_token没有 PKCE 的混合工作流程更安全？

谢谢。

Answer 1

混合流的主要用例是前端和后端需要不同令牌的 Web 客户端：

• Web 前端接收 ID 令牌并可以读取其声明
• 只有 Web 后端接收访问 + 刷新令牌，然后向 Web 前端发出 auth cookie

混合流特性

使用代码 id_token的响应类型进行重定向，并在查询字符串中接收返回的 ID 令牌以及授权代码。为了防止替换攻击，您可以在重定向期间提供随机数值，然后验证响应中是否存在与 ID 令牌声明相同的值。

安全

在安全性方面它与PKCE结合使用。如果谨慎使用，安全性将得到适当考虑并包含在OpenID Connect 规范中。但它需要客户端中更复杂的代码。

此外，如果 ID 令牌中包含姓名和电子邮件等个人数据，则会向浏览器历史记录和服务器日志显示这些数据。这通常是 ID 令牌中需要注意的事情。通常最好从用户信息端点获取此类字段。

金融等级建议

如今，response_type=code通常建议使用 , 在反向通道上接收所有代币。这反映在FAPI 2.0中，现在要求前端通道上不存在 ID 令牌。