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

时间:2019-08-01 05:39:06

标签: oauth oauth-2.0 openid-connect

我一直在阅读有关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令牌 code令牌的实际应用程序的信息,但是除了阅读这些流程中的内容外,第一个令牌是由作为前端通道的授权端点发出的,而通过交换授权码发出的最终令牌是在令牌端点(即后端通道)发出的,因此固有地被认为是更安全的,我无法了解您将用它做什么。任何信息都会很高兴被接受。

2 个答案:

答案 0 :(得分:1)

为什么混合流?经常记录的理由是,在访问令牌仍在获取过程中,您的应用可以通过id_token立即获得有关用户的信息。从技术上讲,这是事实,但仍很少在野外使用。

一个真实的示例是由工作组在OpenID Foundation的保护下开发的金融级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混合流来缓解,其中   诚实的IdP的发行者标识符作为iss的值包括在内。   然后,客户端将代码发送到令牌端点,即   与发行者标识符相关联,因此它不会到达   攻击者。

     

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

     

当受害者和攻击者使用相同的依赖方客户端时,就会发生此攻击。   攻击者能够以某种方式捕获授权代码并   从受害人的授权回应中陈述,并在受害人的回应中使用   自己的授权回复。

     

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

有关这两种攻击和对策的更多技术说明,请参见Single Sign-On Security – An Evaluation of OpenID Connect

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

答案 1 :(得分:0)

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