Aspnetcore: Have an auth-enabled Blazor WASM project template

[mkArtakMSFT]

[javiercn]

• [ ] [Hosted individual auth](https://github.com/dotnet/aspnetcore/issues/18782)
• [ ] [Standalone individual auth](https://github.com/dotnet/aspnetcore/issues/18783)
• [ ] [AAD and AADB2C](https://github.com/dotnet/aspnetcore/issues/18784)

[richbryant]

I'm not opposed on principle but there is a tendency for whatever MS pushes as a template to become the absolute default. Blazor-Webassembly is a SPA framework. None of the Big 3 frameworks come with an Auth template, partly because portability is important and at least partly because there are so many different ways and methods to make it work.

I get the AAD and AADB2C, you kind of have to do those because of reasons. But how will you do the others? Cookies? (ew). External providers? AspNet Identity? JWT?

This is one area where one size does not fit all. I have no doubt you'll do a great job but there's a whole world out there and providing templates is likely to lead projects down a single path which might well be documented in real style but might not actually lead where they need to go.

[javiercn]

@richbryant thanks for the feedback.

I'm not sure about what point you are trying to make. Our all templates have auth options in them and you are free to use them if they fit your needs or not.

This issue is about providing the option to enable authentication out of the box in the template, in the same way we do for the Razor pages, MVC, Web API, Blazor Server and SPA templates.

We choose what we think are the most common and best approaches for each of those scenarios and then let you choose to use it or pick something else.

I get the AAD and AADB2C, you kind of have to do those because of reasons. But how will you do the others? Cookies? (ew). External providers? AspNet Identity? JWT?

• We will not do cookies as it is really hard to get security right.
• External providers will be powered by our own library on top of oidc-client.js
• ASP.NET Identity and JWT are the same and will be powered by the integration we built on top of Identity Server for the SPA templates.

As I said, all these things are additive, you can choose not to use them, but I hope you understand that we have plenty of customers that want to have an auth enabled template out of the box and that you still have the freedom to use these options or not.

I hope that helps clarify things.

[pablopioli]

Your answer is a little contradictory. If you are using Identity Server on the backend you know it uses the current guidance of using cookies for same domain. And you won't be using cookies?

[richbryant]

and AspNet Core Identity is (currently) cookie based by default.

[sowsan]

Does this work with Azure AD OpenId?

[anthcool]

Thanks for this. This will be nice once it's available. Have been looking for a way to get the implicit auth flow with SSO, user identity via AAD, and a data access token figured out for some time now. Looking forward to your progress! For now, I'm looking into using @cradle77 's Nuget for this type of auth, that can be found here: https://github.com/cradle77/Blazor.Msal

[richbryant]

you're not sure what point I'm trying to make?

Okay, I'll try to be very clear. This is a framework for applications which will run on the internet. Security is therefore a huge consideration. If you provide a template, you know as well as I do that 90% of line managers will think "we used the Microsoft template, it's all done the Right Way" means "it's secure". And, in some small number of cases it might be.

But it usually won't.

And this is not about the quality of your template, it's about the fact that security is a cross-cutting concern that is more important than whether you use javascript or c# or whether your server runs AspNet Ccore or node.js.

The process is, as you know, concept -> security -> design.

Security is hard. Giving a template is like allowing mopeds on the freeway. It sounds nice but there's going to be blood.

[sowsan]

Totally got the security concepts and how it can be misinterpreted. I don’t think developers are that stupid to just follow a template. Being these frameworks are pretty new, at least a sample that shows how it works would be great for developers to start with.

[DominikPf]

Thanks for this. This will be nice once it's available. Have been looking for a way to get the implicit auth flow with SSO, user identity via AAD, and a data access token figured out for some time now. Looking forward to your progress! For now, I'm looking into using @cradle77 's Nuget for this type of auth, that can be found here: https://github.com/cradle77/Blazor.Msal

@anthcool It is not longer recommended to use the implicit flow. A better way ist to use authorization code with pkce.

Or even better: Don't use Tokens in your Browser, use Same-Site Cookies. (Current IETF recommendation for OAuth2. Also mentioned by @pablopioli)

Here is a blog post from one of the IdentityServer authors:
https://brockallen.com/2019/01/03/the-state-of-the-implicit-flow-in-oauth2/

[anthcool]

@DominikPf

Thanks for this. This will be nice once it's available. Have been looking for a way to get the implicit auth flow with SSO, user identity via AAD, and a data access token figured out for some time now. Looking forward to your progress! For now, I'm looking into using @cradle77 's Nuget for this type of auth, that can be found here: https://github.com/cradle77/Blazor.Msal

@anthcool It is not longer recommended to use the implicit flow. A better way ist to use authorization code with pkce.

Or even better: Don't use Tokens in your Browser, use Same-Site Cookies. (Current IETF recommendation for OAuth2. Also mentioned by @pablopioli)

Here is a blog post from one of the IdentityServer authors:
https://brockallen.com/2019/01/03/the-state-of-the-implicit-flow-in-oauth2/

Yeah,it is still recommended, but I feel ya on the auth code stuff. It's just SUPER alpha right now so not even really usable.

See:
https://developer.microsoft.com/en-us/identity/blogs/our-thoughts-on-implicit-grant-with-microsoft-identity/

Supposedly supposed to hit with MSAL.js 2.0 I think is what I saw. Was like placed in a March or May release time frame. Even so, implicit flow works for now.