2

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.

MichaelChan
  • 1,808
  • 17
  • 34
  • This is no longer the case. They've updated the [samples](https://github.com/IdentityServer/IdentityServer4/blob/master/samples/Quickstarts/2_InteractiveAspNetCore/src/IdentityServer/Config.cs#L40) a few days ago. Or check [my answer](https://stackoverflow.com/questions/58434954/identityserver4-refresh-tokens-hybrid-flow-cookies-and-storage/58457418#58457418) in case the link changes. –  Oct 24 '19 at 07:19

1 Answers1

2

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.

Community
  • 1
  • 1
Luka Rakic
  • 473
  • 7
  • 15
  • It is correct that PKCE is recommended for SPAs. My question is more on MVC web applications which is for the most part server-side that is why Code is more suitable. So the question remains, How does Web Applications benefit with having id_token on the client side on the initial response (code + id_token)? – MichaelChan Oct 25 '19 at 01:02
  • PKCE is now recommended for MVC also, see here https://github.com/IdentityServer/IdentityServer4/blob/master/samples/Quickstarts/2_InteractiveAspNetCore/src/IdentityServer/Config.cs. Going deeper into whys and hows of tokens and flows is, unfortunately, kinda beyond me, maybe @RuardvanElburg can help you. – Luka Rakic Oct 25 '19 at 07:23
  • 1
    @MichaelChan The id_token is part of the [oidc spec](https://openid.net/specs/openid-connect-core-1_0.html#rfc.section.3.1.3.3) and requested by scope: openid profile (IdentityServer adds the scopes by default). By design, IdentityServer returns a minimal id_token, containing a sub claim only. This id_token is used for verification. On login and also on logout, if provided. There's no need to use or extend the token otherwise. The idea is that the client can request additional info at the UserInfo endpoint. –  Oct 25 '19 at 23:56