Add Auth0 Authentication to Blazor Web Apps

Blog Discussions
, ,
43

Hi @lazer,
Thank you for pointing this out.
I made changes to the code and updated the article. You can see here what has changed from the previous version.

1 Like
44

Thank you again. I am a beginner with Blazor. But this article was perfect!

1 Like
45

In the doc, section " Register your Blazor app with Auth0", step 2 - it says to select “Regular Web Applications” as an application type. On my Create application screen I don’t have that as an option. I do have Web tab, “ASP.NET Core Blazor Server”. What do we select and does the document need updating? Thanks

p.s. Could you also create a second document that continues the first document? The second document would show how to connect the Blazor Web App to an ASP.NET Core API for authentication. Thanks again

46

Hello @LuckyWolf19 ! I went to test this out myself and there might be something wrong so let me investigate this further.

For now you can select any technology like "ASP.NET Core Blazor Server”, this is used so in the next step you see the appropriate Quickstart and instructions for your stack but since you’re following this tutorial you can continue in the next paragraph from the blog post to use the information from the Settings tab

hope this helps and thank you for letting us know about this!

1 Like
47

Thanks @carlastabile that worked. Also, I found this excellent document to help with my p.s. above. Call Protected APIs from a Blazor Web App…_ga_QKMSDV5369MTcyMTc1NTQxMC45LjEuMTcyMTc1NjE3Ny40Ny4wLjA.

48

I’ll add my thanks, @andrea.chiarelli. This was helpful. But from my testing, it doesn’t seem to be doing exactly what you imply. First, I modified the Counter.razor file to show all of the claims; i.e. I created a private ClaimsPrincipal variable in the code called Principal and then put this in the HTML:

@if (Principal != null)
{
    foreach (var userClaim in Principal.Claims)
    {
        <div>@userClaim.Type = @userClaim.Value</div>
    }
}

Then I modified PersistentAuthenticationStateProvider.cs so it only includes a static test claim:

    Claim[] claims = [new Claim(ClaimTypes.Name, "TESTING")];
        //new Claim(ClaimTypes.NameIdentifier, userInfo.UserId),
        //new Claim(ClaimTypes.Name, userInfo.Name ?? string.Empty),
        //new Claim(ClaimTypes.Email, userInfo.Email ?? string.Empty)];

When you run the code like this, the claims that come through are from the original (server-side) principal. I’m guessing because the @rendermode is InteractiveAuto and Blazor first runs the code on the server before sending it to the browser? But even if I change the @rendermode to InteractiveWebAssembly, you’ll see the full set of claims first and then a couple seconds later it’ll be updated with the test claim.

I can work with this, but is there a way to ensure that we don’t get the server-side version of the AuthenticationState when inside a page marked for WASM?

49

Hey @dug, prerendering is enabled by default. To disable it there are a few techniques that work under specific conditions.

50

Okay, thanks. I was trying that, but on the whole site; i.e., updating App.razor so <Routes /> wasn’t prerendered:

 <Routes @rendermode="new InteractiveWebAssemblyRenderMode(prerender:false)" />

but this breaks everything with a “can’t find Routes” error, because Routes is rendered server-side, and I’m telling it everything has to be client-side. (I assume?)

What seems to work is to put @rendermode on the page itself, i.e. in the Counter.razor file:

@page "/counter"
@using System.Security.Claims
@attribute [Authorize]
@rendermode @(new InteractiveWebAssemblyRenderMode(prerender:false))

This means the Counter page won’t appear until the client-side authentication state has been loaded, so the server-side authentication state never appears. If I want to ensure that client-side pages never see the server-side authentication (which I do), then I’m either going to add the @rendermode to every page or create a base class for it. Not great, but I don’t see any other way around it.

Anyway, thanks. This was very helpful.

PS In case you’re curious about use case for all this, I’ve got a POS system where a supervisor logs in, but then any approved staff member can be running the app, by choosing from a dropdown then entering their special code. So my server-side auth is actually Auth0 but my client-side “auth” is of my own making, and I don’t want the former to show through to the latter.

1 Like
51

Thank you @andrea.chiarelli Great article!!! It worked perfectly for me. Without it, I probably would have been stuck for weeks.

1 Like
52

Hey @hex29a, thank you very much for your feedback! I appreciate it a lot :heart: