我什么时候在 OpenID Connect 中使用带有 response_type=code id_token 令牌的混合流？

Question

我一直在阅读有关 OpenId Connect 及其隐式流、授权代码流和混合流的流。

我知道，例如，隐式流程有点不安全，应该只在公共客户端（如 SPA 应用程序）中使用。

现在我正在尝试了解可用于非公共应用程序（如 .Net MVC 应用程序）的混合流，在这些应用程序中您有反向通道通信，因此您可以保存一个秘密密码。

阅读混合流我知道它有 3 种不同类型的 response_type，可以是：

1. 代码 id_token
2. 代码令牌
3. 代码 id_token 令牌

对我来说，最好的 response_type 是代码 id_token，我可以在其中获取前端通道中的代码，然后将该代码发送到 Identity Server Provider 并通过后端通道获取访问令牌。

我一直在搜索有关 response_type=code id_token token 或 code token 的实际应用程序的信息，但除了在这些流程中阅读第一个令牌由作为前端通道的授权端点发出，通过交换授权码发出的最终令牌在作为反向通道的令牌端点发出，因此本质上被认为更安全，我没有了解您将其用于什么。我们很乐意接受任何信息。

Answer 1

为什么是混合流？经常记录的理由是，您的应用程序可以通过 id_token 立即获得有关用户的信息，而访问令牌仍在进行中。从技术上讲，这是正确的，但它仍然很少在野外使用。

一个真实的示例是由 OpenID 基金会旗下的一个工作组开发的金融级 API (FAPI) 配置文件。出于安全原因，它建议使用混合流。值得注意的是，流的通道拆分“功能”本身不足以提供所需的安全属性，还需要来自其他移动部件的更多“合作”。来自FAPI implementer's draft part 2：

此配置文件描述了服务器和客户端的安全规定 通过定义度量来适用于金融级 API 减轻：

• 利用 [RFC6749] 中端点弱绑定的攻击（例如恶意端点攻击、IdP 混合攻击），
• 通过利用返回的 OpenID Connect 的混合流来修改 [RFC6749] 中不受保护的授权请求和响应的攻击 授权响应中的 ID 令牌。

和细节

8.3.3 身份提供者 (IdP) 混淆攻击

在这次攻击中，客户端拥有 注册了多个 IdP，其中一个是返回的流氓 IdP 属于诚实 IdP 之一的同一 client_id。当一个用户 点击恶意链接或访问受感染的网站， 授权请求被发送到流氓 IdP。然后是流氓 IdP 将客户端重定向到具有相同 client_id 的诚实 IdP。如果 用户已经在诚实的 IdP 上登录，然后 可以跳过身份验证并生成代码并返回给 客户端。由于客户端正在与流氓 IdP 交互，因此 代码被发送到流氓 IdP 的令牌端点。在这一点上， 攻击者有一个有效的代码，可以在 诚实的 IdP。

使用 OpenID Connect Hybrid Flow 可以缓解这种情况，其中 诚实 IdP 的颁发者标识符作为 iss 的值包含在内。 然后客户端将代码发送到令牌端点 与发行者标识符相关联，因此它不会到达 攻击者。

8.4.3。授权响应参数注入攻击

当受害者和攻击者使用相同的依赖方客户端时，就会发生这种攻击。 攻击者能够以某种方式捕获授权代码并 从受害者的授权响应中状态并在他的 自己的授权响应。

这可以通过使用 OpenID Connect Hybrid Flow 来缓解，其中 可以使用c_hash、at_hash和s_hash来验证 授权码、访问令牌和状态参数。服务器可以 验证状态是否与浏览器中存储的状态相同 授权请求时的会话。

有关这两种攻击和对策的更多技术描述，请参阅Single Sign-On Security – An Evaluation of OpenID Connect

要获得非常详细的描述，请查看OIDC Security Analysis 论文。

Answer 2

混合流允许后端以离线方式（当用户不再存在通过浏览器发送请求时）或独立于前端......并行执行其他操作。它可以使用反向通道交换的刷新令牌来继续获取新的访问令牌并无限期地工作。