Request: Change sample to use the OIDC 'authorization code flow' instead of the less secure 'implicit flow'.

[colgreen]

Hi. This demo is currently using the OIDC 'implicit flow', which is no longer recommended by the IETF. As such it would be good to get the demo changed to use the OIDC 'Authorization code flow' instead.

From:

https://oauth.net/2/grant-types/implicit/

The Implicit flow was a simplified OAuth flow previously recommended for native apps and JavaScript apps where the access token was returned immediately without an extra authorization code exchange step.

It is not recommended to use the implicit flow (and some servers prohibit this flow entirely) due to the inherent risks of returning access tokens in an HTTP redirect without any confirmation that it has been received by the client.

Public clients such as native apps and JavaScript apps should now use the authorization code flow with the PKCE extension instead.

The OAuth 2.0 Security Best Current Practice document recommends against using the Implicit flow entirely, and OAuth 2.0 for Browser-Based Apps describes the technique of using the authorization code flow with PKCE instead.

That is, the 'implicit flow' was designed to be used by client side (i.e. browser) single page apps (SPAs) that are hosted on a lightweight/dumb web server, i.e. hosting the app as static content only.

In the ASP.NET integration with OIDC, the server takes part in the authorization flow, and can therefore implement the more secure 'authorization code flow'. See:

https://oauth.net/2/grant-types/authorization-code/

In this mode, the identity provider (IdP) returns a simple 'authorization code' to the browser (instead of an access token), the browser passes this to the ASP.NET server, which then redeems it for an access token - in this final step the server supplies a client secret known only to the server and IdP, thus adding an extra level of security.

Here is a demo app that appears to be using authorization code flow:

• forms45-oidc-sample

E.g. in Startup.cs it does:

  ResponseType = OpenIdConnectResponseType.CodeIdToken,

Instead of

  ResponseType = OpenIdConnectResponseType.IdToken,

[colgreen]

@Shama-K Hi, I also raised this issue some time ago; do you know if there are plans to look into this? I will be looking into this soon, so if I learn how to do it I will issue another PR with the required changes.

[jmprieur]

Not that CodeIdToken is not implict flow by hybrid flow. We are changing the words in the portal to avoid confusion

[Shama-K]

@colgreen, this pull request handles above issue along with other points that you have raised on earlier pull request.
As mentioned by Jean-Marc, CodeIdToken is hybrid flow and you can get more information about response types here: OpenIdConnectResponseType Class
Thanks.

[colgreen]

@Shama-K Hi, sorry, I think my comment about use of OpenIdConnectResponseType.CodeIdToken was not helpful. I think we should change that value back to OpenIdConnectResponseType.IdToken for now.

To change the demo to use the 'authorization code flow' will require more than that change, and probably some research to determine how (and if!) it can be done using the Microsoft.Owin packages.

[colgreen]

@Tratcher, can you shed some light on this? I.e. do you agree that the 'code flow' is appropriate for this demo app? And do you know if it is possible to do it using the Microsoft.Owin packages? Thanks.

[Tratcher]

Code flow support was added to the Microsoft.Owin package in the 4.1 (aspnet/AspNetKatana#297). It was not made the default for backwards compatibility reasons. There's also a PR pending to add PKCE support (aspnet/AspNetKatana#389).

I don't think you'd want to recommend code flow in this sample without PKCE support.

[colgreen]

Thanks @Tratcher . My understanding is that the code flow is appropriate and recommended where there is a web server that is able to redeem the code on a backchannel. If I am understanding right, that is recommended regardless of whether PKCE is used or not.

The thing that would not be recommended is redeeming the code from the browser (i.e. no server backchannel) without PKCE.

As such could you expand on your final comment:

I don't think you'd want to recommend code flow in this sample without PKCE support.

We can drop this if you like. I just think if we have a 'flagship' demo of using OIDC in ASP.NET Framework, then it should be up-to-date and using the best/recommended flow that we can support right now.

Thanks for your time.