<p>Why hybrid flow? The oft-documented rationale is that your app can immediately have info about the user via the id_token while the access token acquisition is still in flight. Technically this is true but it's still rarely used in the wild.</p>

<p>One real-world example is a Financial-grade API (FAPI) profile developed by a working group under the umbrella of OpenID Foundation. It recommends hybrid flow for security reasons. It's worth noting that the channel split "feature" of the flow is not enough on its own to provide the desired security properties, more "cooperation" from other moving parts is needed. From <a href="https://openid.net/specs/openid-financial-api-part-2-ID2.html" rel="nofollow noreferrer">FAPI implementer's draft part 2</a>:</p>

<blockquote>
  <p>This profile describes security provisions for the server and client
  that are appropriate for Financial-grade APIs by defining the measures
  to mitigate:</p>
  
  <ul>
  <li>attacks that leverage the weak binding of endpoints in [RFC6749] (e.g. malicious endpoint attacks, IdP mix-up attacks),</li>
  <li>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.</li>
  </ul>
</blockquote>

<p>and details</p>

<blockquote>
  <p>8.3.3 Identity provider (IdP) mix-up attack </p>
  
  <p>In this attack, the client has
  registered multiple IdPs and one of them is a rogue IdP that returns
  the same <code>client_id</code> 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 <code>client_id</code>. 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.</p>
  
  <p>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 <code>iss</code>.
  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.</p>
  
  <p>8.4.3.  Authorization response parameter injection attack </p>
  
  <p>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.</p>
  
  <p>This can be mitigated by using OpenID Connect Hybrid Flow where the
  <code>c_hash</code>, <code>at_hash</code>, and <code>s_hash</code> 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.</p>
</blockquote>

<p>For a more technical description of these two attacks and countermeasures, see <a href="https://www.nds.rub.de/media/ei/veroeffentlichungen/2017/01/30/oidc-security.pdf" rel="nofollow noreferrer">Single Sign-On Security – An Evaluation of OpenID Connect</a> </p>

<p>For a realllly detailed description, take a look at <a href="https://arxiv.org/abs/1704.08539" rel="nofollow noreferrer">OIDC Security Analysis</a> paper. </p>
When would I use a Hybrid flow with response_type=code id_token token in OpenID Connect?
<p>I have been reading about OpenId Connect and their flows that are <strong>implicit flow</strong>, <strong>authorization code flow</strong> and <strong>hybrid flow</strong>.</p>

<p>I know that for example, the implicit flow is kind of insecure and should be used just in public clients like SPA application.</p>

<p>Now I´m trying to understand the Hybrid Flow that can be used for non-public applications like .Net MVC applications where you have a backchannel communication and thus you can save a secret password.</p>

<p>Reading about the Hybrid flow I know that it has 3 different types of response_type that can be:</p>

<ol>
<li>code id_token</li>
<li>code token</li>
<li>code id_token token</li>
</ol>

<p>For me, the best response_type would be code id_token where I can get the code in the front channel and then send that code to the Identity Server Provider and get the access token through the backchannel.</p>

<p>I've been searching for information on a real-world application of <strong>response_type=code id_token token</strong>, or <strong>code token</strong>, but other than reading that in these flows the first token/s are issued by the authorization endpoint which is the front channel and the final tokens that are issued by exchanging the authorization code are issued at the token endpoint, which is the backchannel and thus inherently accepted as being more secure, I fail to understand what you would use this for. Any information would be gladly accepted.</p>