在OpenID Connect中，何时应使用response_type=code id_token token的混合流？

Question

我一直在阅读关于OpenId Connect和它们的流程，包括隐式流程、授权码流程和混合流程。

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

现在我正在尝试理解混合流程，可以用于非公开应用程序，如.Net MVC应用程序，在这些应用程序中有一个后台通信，因此您可以保存秘密密码。

通过阅读混合流程，我知道它有三种不同的response_type，分别是：

1. code id_token
2. code token
3. code id_token token

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

我一直在搜索适用于response_type=code id_token token或code token的实际应用程序的信息，但除了阅读这些流程的第一个令牌/ s由授权终端点发出，这是前端通道的情况外，最终令牌通过交换授权代码在令牌终端点发放，这是后台通道的情况，因此本质上被视为更安全，我无法理解您将其用于什么。 欢迎提供任何信息。

- mavi

Answer 1

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

一个真实的例子是OpenID基金会旗下的工作组开发的金融级API（FAPI）配置文件。它建议出于安全原因使用混合流。值得注意的是，流程的通道分离“功能”本身并不足以提供所需的安全属性，需要其他移动部件的更多“协作”。来自 FAPI实施者草案第2部分：

此配置文件通过定义适用于金融级API的服务器和客户端的安全条款来描述安全措施，以减轻：

- 利用[RFC6749]中端点的弱绑定（例如，恶意端点攻击、IdP混淆攻击）的攻击； - 利用OpenID Connect的混合流，在授权响应中返回ID Token，修改未受[RFC6749]保护的授权请求和响应的攻击。

详见。

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 可用于验证授权代码、访问令牌和状态参数的有效性。服务器可以验证状态是否与授权请求时存储在浏览器会话中的内容相同。

对于这两种攻击和对策的更详细技术描述，请参见单点登录安全 - 对OpenID Connect的评估。

对于更加详细的描述，请查看OIDC安全分析论文。

- identigral

Answer 2

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

- cleber oliveira