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

Question

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

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

现在我正在尝试了解可用于非公共(public)应用程序的混合流，例如 .Net MVC 应用程序，在这些应用程序中您可以进行反向 channel 通信，因此可以保存 secret 密码。

阅读混合流程我知道它有 3 种不同类型的 response_type 可以是:

1. 代码id_token
2. 代码 token
3. 代码 id_token token

对我来说，最好的 response_type 是代码 id_token，我可以在其中获取前端 channel 中的代码，然后将该代码发送到身份服务器提供程序并通过后台 channel 获取访问 token 。

我一直在搜索有关response_type=code id_token token 或code token 实际应用的信息，但除了在这些流程中阅读第一个 token 由作为前 channel 的授权端点颁发，通过交换授权代码颁发的最终 token 在作为后 channel 的 token 端点颁发，因此本质上被认为更安全，我无法做到了解您将使用它做什么。我们很乐意接受任何信息。

Answer 1

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

一个真实的例子是由 OpenID 基金会旗下的一个工作组开发的金融级 API (FAPI) 配置文件。出于安全原因，它推荐混合流。值得注意的是，流的 channel 拆分“功能”本身不足以提供所需的安全属性，需要其他移动部件的更多“合作”。来自 FAPI implementer's draft part 2 :

This profile describes security provisions for the server and client that are appropriate for Financial-grade APIs by defining the measures to mitigate:

• attacks that leverage the weak binding of endpoints in [RFC6749] (e.g. malicious endpoint attacks, IdP mix-up attacks),
• attacks that modify authorization requests and responses unprotected in [RFC6749] by leveraging OpenID Connect's Hybrid Flow that returns an ID Token in the authorization response.

和细节

8.3.3 Identity provider (IdP) mix-up attack

In this attack, the client has registered multiple IdPs and one of them is a rogue IdP that returns the same client_id that belongs to one of the honest IdPs. When a user clicks on a malicious link or visits a compromised site, an authorization request is sent to the rogue IdP. The rogue IdP then redirects the client to the honest IdP that has the same client_id. If the user is already logged on at the honest IdP, then the authentication may be skipped and a code is generated and returned to the client. Since the client was interacting with the rogue IdP, the code is sent to the rogue IdP's token endpoint. At the point, the attacker has a valid code that can be exchanged for an access token at the honest IdP.

This is mitigated by the use of OpenID Connect Hybrid Flow in which the honest IdP's issuer identifier is included as the value of iss. The client then sends the code to the token endpoint that is associated with the issuer identifier thus it will not get to the attacker.

8.4.3. Authorization response parameter injection attack

This attack occurs when the victim and attacker use the same relying party client. The attacker is somehow able to capture the authorization code and state from the victim's authorization response and uses them in his own authorization response.

This can be mitigated by using OpenID Connect Hybrid Flow where the c_hash, at_hash, and s_hash can be used to verify the validity of the authorization code, access token, and state parameters. The server can verify that the state is the same as what was stored in the browser session at the time of the authorization request.

有关这两种攻击和对策的更多技术描述，请参阅 Single Sign-On Security – An Evaluation of OpenID Connect

有关非常详细的说明，请查看 OIDC Security Analysis纸。