Why not use AuthenticationStateProvider and CascadingAuthenticationState vs. binding it into the TodoApp.razor

[richp582]

Just wondering about the decision to bind the CurrentUser and Providers into the TodoApp.razor file and hosting it manually in the _Host.cshtml from the BFF file vs. using a [Custom]AuthenticationStateProvider with CascadingAuthenticationState in the App.Razor and then protecting your pages with the [Authorize] attribute.

I used some of the auth logic from this sample repo to build my current app, but am using a CustomAuthenticationStateProvider with CascadingAuthenticationState and wanted to know if there was some considerations I'm missing.

Thanks a lot for this awesome sample, was a massive help!!

[Moerty]

That would also interest me

[davidfowl]

I did what initially came to mind first. I'll take a look at what it would mean to implement an AuthenticationStateProvider.

cc @SteveSandersonMS for any thoughts.

[SteveSandersonMS]

A custom AuthenticationStateProvider would also work fine here and would be a bit more integrated with other Blazor auth mechanisms (e.g., AuthorizeView etc.). And it means that any component that wants to work with auth state can get it without needing it to be passed manually throughout the component hierarchy.

However the approach used here (manually passing in the CurrentUser string) will also work entirely fine. It's a bit more manual and low-level but has the benefit of being completely explicit and reducing the concept count.

For a larger app, using an AuthenticationStateProvider would give more flexibility so I would recommend it. For a small app like this, it doesn't make much difference either way and is only a matter of preference/convenience.

[davidfowl]

I'd like to make it more blazor idiomatic, so it seems like an AuthenticationStateProvider is the way to go.