为什么要使用混合流?常见的理由是,通过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安全分析论文。