Does ASP.NET Core's authentication middleware always use implicit flow for OpenID Connect?

Question

Setting up a simple out-of-the-box ASP.NET Core MVC app in Visual Studio 2019 with authentication enabled against an Azure Active Directory will result in implicit OAuth2 flow while using OpenID-Connect.

This is illustrated here.

I just tested this and I did not have to deal with a client secret which would be mandatory for authorization code flow, so I presume above is true.

On the other hand in the documentation the use of the implicit flow is discouraged:

The implicit grant presents more risks than other grants, [...] If you are developing a Web application that includes a backend, and consuming an API from its backend code, the implicit flow is also not a good fit.

To further confuse things, there is this documentation where it is stated that web apps are using the authorisation code flow:

The OAuth 2.0 authorization code flow is described in section 4.1 of the OAuth 2.0 specification. It's used to perform authentication and authorization in the majority of app types, including web apps and natively installed apps.

The questions that arise are

• If the implicit flow is considered a bad choice, why is it used by the ASP.NET Core MVC middleware?
• Can I change the behaviour?
• If yes, where and how would I be able to obtain the client secret from Azure AD's app registration?

Answer 1

Your observations are, unfortunatelly valid.

The samples provided use implicit flow. I would guess for simplicity. This can be seen from the configuration script for the latest sample.

All the statements regarding implicit flow are correct. Including the one from the comment.

However, we have to pay attention, that the default scaffolding of ASP.NET Core project that uses OpenID Connect, actually only performs authentication and not authorization. It also does not perform a calls to external APIs. In that sense, the implicit flow is used to only obtain an id_token, but not access_token. The former contains user profile information and does not pose security risk. Whereas the latter contains authorization data for accessing specific resource. So the id_token itself does not impose a security risk when leaked. Yes it imposes data leak if leaked, but not a security one.

There is more complete sample here. Which uses ob-behalf-of flow to get an access_token to call external service. It is still not the full authorization code grand flow, but the on-behalf-of flow. The latter is even more secure.

Generally speaking OpenIDConnect implementation in .NET Core does have implementation for handling authorization code, which can be seen from the AuthorizationCodeRecieved event. Which can be used when constructing OpenIdConnectOptions object by defining the OpenIDConnectEvents property.

Frankly, to ask why project scaffolds are so designed will not bring a lot of attention, neither will it change it something. I am pretty sure the older implementations (.net 4.5 or so) were using AuthZ Code by default. Not sure why this has changed - probably to lower the friction of implementation and understanding of samples ....

But hey, IMO using Authorization Code grand to just get an ID token is a bit of an overkill, isn't it?

Addressing the comments

1) Agree it is a mess. Authorize attribute does nothing but checking for authenticated user. It may also be configured to check for a specific role. But even then, that role will be extracted from the id_token. Because you do not have access_token in case of a web app. My point is, thet when you deal with a simple web app (front end, backend - Controllers or ASPX pages) you only deal with id_tokens and no access tokens. In that context having implicit flow significantly reduces the code complexity.

The documentation is open sourced on GitHub and any responsible programmer has the freedom (and is more then welcome) to suggest improvements or indicate problems. While StackOverflow is for technical questions and answers, not complaints about software documentation.