Why is hybrid flow the default recommended option for Web Applications in identityserver?

Viewed 1230

I've built my own identity server using identity server 4. One of the things I often see in examples and even administration UIs is that for web applications (typically MVC), Hybrid is the default grant type (flow). I just don't see how it is beneficial.

response type: code token

  1. id_token is returned on the code/token exchanged anyway even when response type is "code".
  2. id_token isn't normally useful on the client side since the client would have to process the JWT first and most of the information can be sent to the view.
  3. Even for SPAs, if I set the response type to only code, I still get an id_token (through oidc-client).

What use case am I missing where id_token sent on the initial response would be important enough to the view? I'm using authorization_code grant type but I'm curious when I should use hybrid.

1 Answers

As far as I understand, currently the preferred flow is Code with PKCE. In .Net Core 2, hybrid was default probably because .Net Core 2 does not include built-in support for PKCE, but the new .Net Core 3 does, and in the words of IS4 documentation:

"PKCE is already the official recommendation for native applications and SPAs - and with the release of ASP.NET Core 3 also by default supported in the OpenID Connect handler as well."

Hybrid was used because it solved the code substitution attack, but it creates the following downsides:

1."the id_token gets transmitted over the font-channel and might leak additional (personal identifiable) data"

2."all the mitigitation steps (e.g. crypto) need to be implemented by the client. This results in more complicated client library implementations."

With the introduction of PKCE, which also solves the substitution problem, PKCE becomes the simpler solution. This is from Scott Brady:

"It used to be best practice to use the hybrid flow response type of code id_token as this gave us something to verify before swapping code for tokens (via the nonce and c_hash parameters). However, since we’re now using PKCE, the injection of codes to impersonate another user is no longer a risk. As a result, we can safely remove all PII (identity tokens) from the browser."

Hope this answers your question, since my understanding of the matter is rather mediocre. Links used:
IS4 Documentation
ASP.NET Core Support for PKCE by Scott Brady
OAuth 2.0 Security Best Current Practice

EDIT: There seems to be a similar question with an answer here.

Related