何时在response_type=code连接中使用带有id_token令牌的混合流？
我一直在阅读OpenId连接及其流，即隐式流、授权代码流和混合流。
例如，我知道隐式流有点不安全，应该只在像SPA应用程序这样的公共客户机中使用。
现在，我正在尝试理解混合流，它可以用于非公共应用程序，如.Net MVC应用程序，其中您有一个反向通道通信，因此您可以保存一个秘密密码。
阅读混合流时，我知道它有3种不同类型的response_type，可以是：
- 代码id_token
- 代码令牌
- 代码id_token令牌
对我来说，最好的response_type是代码id_token，在这里，我可以在前面的通道中获取代码，然后将代码发送到Identity Server提供程序，并通过反向通道获取访问令牌。
我一直在搜索关于response_type=code id_token token或代码令牌的真实应用程序的信息，但是除了阅读到在这些流中第一个令牌/s是由授权端点(也就是前端通道)发出的，而且通过交换授权代码发出的最终令牌在令牌端点上发出，而令牌端点是反向通道，因此本质上被接受为更安全，我不明白您将使用它做什么。任何信息都将被欣然接受。
回答 2
Stack Overflow用户
发布于 2019-08-01 07:28:16
为什么是混合流？oft文档的基本原理是，您的应用程序可以立即通过id_token获得有关用户的信息，而访问令牌的获取仍在进行中。从技术上讲，这是正确的，但在野外仍然很少使用。
一个真实的例子是一个由OpenID基金会下属的工作组开发的金融级API (FAPI)概要文件。出于安全考虑，它建议混合流。值得注意的是，流的通道拆分“特性”本身并不足以提供所需的安全属性，需要其他移动部件提供更多的“协作”。来自FAPI实现者草案第2部分
本概要描述了服务器和客户端适用于金融级API的安全规定，方法是定义减轻以下问题的措施：
- 利用RFC6749中端点弱绑定的攻击，
- 通过利用RFC6749连接的混合流(返回授权响应中的ID令牌)来修改授权请求和在OpenID中不受保护的响应的攻击。
和细节
8.3.3身份提供者(IdP)混合攻击 在这次攻击中，客户已经注册了多个国内流离失所者，其中之一是一个流氓IdP，它返回属于一个诚实的国内流离失所者的同一个
client_id。当用户单击恶意链接或访问受损站点时，授权请求将发送给流氓IdP。然后，流氓IdP将客户端重定向到具有相同client_id的诚实IdP。如果用户已经在诚实的IdP上登录，那么可以跳过身份验证，生成一个代码并返回给客户端。由于客户端与流氓IdP交互，代码被发送到流氓IdP的令牌端点。此时，攻击者有一个有效的代码，可以在诚实的IdP上交换访问令牌。 这是通过使用OpenID连接混合流来缓解的，其中诚实的IdP的发行者标识符包含在iss的值中。然后，客户端将代码发送到与颁发者标识符关联的令牌端点，因此不会到达攻击者。 8.4.3.授权响应参数注入攻击 当受害者和攻击者使用同一个依赖方客户端时，就会发生此攻击。攻击者可以从受害者的授权响应中获取授权代码和状态，并在自己的授权响应中使用这些代码和状态。 这可以通过使用OpenID连接混合流来缓解，其中可以使用c_hash、at_hash和s_hash来验证授权代码、访问令牌和状态参数的有效性。服务器可以验证状态是否与授权请求时存储在浏览器会话中的状态相同。
有关这两种攻击和对策的更多技术说明，请参见单点安全-- OpenID连接的一种评价。
要获得详细的描述，请看一看OIDC安全分析的论文。
Stack Overflow用户
发布于 2021-05-17 03:44:19
混合流允许后端继续以脱机方式(当用户不再存在通过浏览器发送请求时)或独立于前端的方式代表用户.并行地做其他事情。它可以使用反向通道交换刷新令牌继续获得新的访问令牌并无限期地工作。
https://stackoverflow.com/questions/57302426
复制相似问题
腾讯云开发者
