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

Question

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

\n\n

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

\n\n

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

\n\n

阅读有关混合流的内容后，我知道它有 3 种不同类型的 response_type：

\n\n

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

\n\n

对我来说，最好的response_type是代码id_token，我可以在前面的通道中获取代码，然后将该代码发送到身份服务器提供程序并通过反向通道获取访问令牌。

\n\n

我一直在寻找有关response_type=code id_token token或code token的实际应用程序的信息，但除了阅读这些流程中的第一个令牌是由授权端点（即前端通道）和通过交换授权代码发出的最终令牌是在令牌端点（即反向通道）发出的，因此本质上被认为更安全，我无法理解您将使用它做什么。任何信息都会很乐意接受。

\n

Answer 1

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

\n\n

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

\n\n

\n

此配置文件描述了适用于金融级 API 的服务器和客户端的安全规定，\n 通过定义缓解措施\n：

\n\n

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

\n

\n\n

和细节

\n\n

\n

8.3.3 身份提供商（IdP）混淆攻击

\n\n

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

\n\n

通过使用 OpenID Connect 混合流可以缓解这种情况，其中诚实 IdP 的颁发者标识符作为 的值包含在内iss。然后，客户端将代码发送到与颁发者关联的令牌端点标识符，因此攻击者无法获取它。

\n\n

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

\n\n

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

\n\n

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

\n

\n\n

有关这两种攻击和对策的更多技术说明，请参阅单点登录安全 \xe2\x80\x93 OpenID Connect 的评估

\n\n

有关真正详细的描述，请查看OIDC 安全分析论文。

\n