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
Thank you again. I am a beginner with Blazor. But this article was perfect!
1 Like
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
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
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.
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?
Hey @dug, prerendering is enabled by default. To disable it there are a few techniques that work under specific conditions.
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
Thank you @andrea.chiarelli Great article!!! It worked perfectly for me. Without it, I probably would have been stuck for weeks.
1 Like
Hey @hex29a, thank you very much for your feedback! I appreciate it a lot 
@andrea.chiarelli Thank you for the excellent article. For my work I made our Blazor Server authentication flow which communicates with official, Belgian IdP through Keycloak. Soon we’ll be refactoring a number of applications to make use of Blazor’s mixed render modes so this has proven invaluable.
I’ve gotten it all wired up for a hobby project first and will continue tinkering for a while. I’ve noticed you’ve already put up an article on how to handle secure communication with an external API, so I’m definitely looking forward to that one too.
Hey @RenegadeVile,
Thank you so much for sharing this I’m happy my articles were helpful for your projects 
Hey @andrea.chiarelli - First of all, love you guys for providing these sort of examples! Great article and your examples play a huge role in adopting your products.
I have a quick question - I have a blazor 9 app published on k8s behind reverse proxy on a subpath. I have done a lot of “hacks” 
to make your example work, however one thing is not working still, not sure what’s wrong.
This is the post logon redirect which is wrong for some reason on the root, instead of subpath - so it goes to “/”, instead of “/subpath/” after navigating to proper “/subpath/callback”? (breaks my mind why)
Hey @roman.kondratyev, thank you very much for appreciating our content 
Your feedback energizes us to do an even better job 
Regarding your problem, I’m not totally sure about the actual cause. Have you configured your app to work behind proxies? Take a look here.
Hello @andrea.chiarelli, thank you so much for the detailed article. I have very nearly achieved my goal of implementing user authentication using the steps in this article. However, I have deviated slightly from your tutorial and have gotten stuck on a single feature which worked very well in the original. If the user is not authenticated and they visit one of the pages which has the “Authorize” attribute specified, the user would then be redirected to the Auth0 login page for my app. This feature is not working for me currently. What I see instead is a static string saying “Not Authorized” being displayed on the restricted page. I was able to see this is defined in the AuthorizeRouteView because I can customize what is displayed through the AuthorizeRouteView.NotAuthorized property. The only difference for my project that I can think would impact this feature is the following: I have specified Global Auto interactivity in my project, and therefore my Routes.razor and MainLayout.razor files are in the Client project, not the Server project. I am new to Blazor and am having a hard time figuring out exactly how the AuthorizeRouteView component and the Authorize attribute facilitate the feature I mentioned, so I am struggling to get it to work for my project. Any advice is greatly appreciated! Let me know if there is any other information you would need to explain why this feature might not be working.
Hey @jeremyperna7254,
Thank you for appreciating my article and joining the Auth0 Community!
The approach to authentication shown in the article uses server-side processing, which is inherently more secure. This means that all the authentication steps (routing to the Auth0 login page and getting the tokens) occur on the server side.
For this reason, all the components involved in the authentication steps must be processed on the server, including the Routes.razor component.
To fix the issue, you should bring the Routes.razor and the Layout stuff on the server.
I don’t know how complex your project is, but my suggestion is to scaffold it from scratch and avoid using Global as an interactivity location.
By the way, you can get a working Blazor WebApp in minutes using the Auth0 Templates for .NET.
Great article Andrea.
Sorry for posting this issue here and not in a new topic but I’m struggling to find out how to do that on this community (is it a permission thing?). If you want me to re-create the issue in a new topic I can if you can guide me how to do that…?
I’m finding that the access token retrieved in my back-end code never has any permissions:
My Auth0 setup is as follows:
-
I have created a “Regular Web Application” as per the article and set the ClientId, ClientSecret and Domain in config. I’m also making sure that I pass the correct Audience (see step 5. below)
-
I have a an API with an audience of
https://cloudoko-portal-api/and I’ve toggled Enable RBAC and Add permissions in the Access Token -
The api specifies 3x permissions
create:weatherread:weatherupdate: weather -
I have a role called
Weather Reader→ which grantsread:weatherpermission -
My user has been granted the
Weather Readerrole (I want to test I only get the 1 permission) -
I have set the Auth0 authentication config in Program.cs as follows
builder.Services.AddAuth0WebAppAuthentication(options =>
{
options.Domain = auth0Configuration.Tenant; // My tenant name
options.ClientId = auth0Configuration.ClientId; // The client id of the application
options.ClientSecret = auth0Configuration.ClientSecret; // The client secret of the application
})
.WithAccessToken(options =>
{
options.Audience = auth0Configuration.Apis["PortalApi"].Identifier; // This resolves to 'http://cloudoko-portal-api'
options.Scope = "email read:weather"; // the custom permission / scopes I need to see in the access token
options.UseRefreshTokens = true;
});
- In my code I am retrieving the access token as follows:
var accessToken = await _httpContextAccessor.HttpContext.GetTokenAsync("access_token");
But no matter when I do the access token never contains anything in the permissions claim???
I’ve followed all the examples I can find on this community - they all seem to point towards something being wrong about the audience in the /authorize request. But I’ve checked my config over and over and as you can see in the token it’s showing the right audience - so what else could be stopping Auth0 from resolving permissions correctly? Is this a .NET SDK issue???
I’ve also read the guidance on enabling RBAC and noted that Auth0 will change your access token to access_token_authz or rfc9068_profile_authz depending on what your AccessTokenProfile is set to for the API - mine is set to “Auth0” but I’ve checked both tokens regardless and each of these statements always returns a null.
var accessToken = await _httpContextAccessor.HttpContext.GetTokenAsync("access_token_authz"); // Returns null
var accessToken = await _httpContextAccessor.HttpContext.GetTokenAsync("rfc9068_profile_authz"); // Returns null
Appreciate any help you or anyone else reading this can give - I’ve burned hours on this and would really like to use the Auth0 RBAC feature in my Blazor Auto application - to save having to roll my own.
Thanks
Matt
P.S. I tried to attach screenshots so people could check my work but it won’t let me 
Hi @matthew.wynn,
Welcome to the Auth0 Community. Sorry that you experienced issues in creating this post. As far as I know, you should be able to post new topics and upload screenshots 
Anyway, let’s focus on your problem first.
At first glance, you did the correct steps to add permissions to the access token. Not sure why it is not working, honestly. Do you have a sample project on a public repo that I can take a look at or debug?
Just a small note on your code (I don’t think this is the root of the problem, but just to clarify). I would write it as follows:
builder.Services.AddAuth0WebAppAuthentication(options =>
{
options.Domain = auth0Configuration.Tenant; // My tenant name
options.ClientId = auth0Configuration.ClientId; // The client id of the application
options.ClientSecret = auth0Configuration.ClientSecret; // The client secret of the application
options.Scope = "openid profile email";
})
.WithAccessToken(options =>
{
options.Audience = auth0Configuration.Apis["PortalApi"].Identifier; // This resolves to 'http://cloudoko-portal-api'
options.UseRefreshTokens = true;
});
Not sure if you want to check scopes and permissions or just permissions (see here for the difference). To simplify, I assume you are actually going to check permissions, so you don’t need to specify the read:weather scope in the access token options. Permissions are bound to the user, so you should see them in the access token regardless of whether you specify the read:weather scope or not.
Let me know if you can share your code.
Hi Andrea,
Thanks for coming back to me so quickly.
Noted on the placement of the scope configuration. I couldn’t work out where it was best to do that. Either inside .AddAuth0WebAppAuthentication() or inside .WithAccessToken() - thanks for confirming that it should be the former. Could you explain why there are two places to configure scope in the SDK?
To answer your other question - in my code I’m trying to inspect the contents of the permissions claim (which is always an empty array) not the scope claim - thanks for the article, I will read that multiple times until it sinks in 
I can happily share my code with you - is there some way we can connect privately so I don’t have to post it on a public forum?
Alternatively - what might be easier for you is that I’ve managed to replicate the issue using the Auth0 ASP dot NET Core Blazor Server Quickstart application - here’s what I did:
-
I went back to the same “Regular Web Application” I mentioned that I had created the post above, and downloaded the sample application from the Quickstart tab in Auth0 admin area. This gave me a pre-configured sample .NET 6.0 app to use against the Auth0 application where I’m having this problem.
-
I followed instructions in the Quickstart to configure the additional Allowed Callback Urls and Allowed Logout Urls to my Auth0 Regular Web Application
BTW - I went with the https localhost:7113 route not the http localhost:3000 that the Quickstart screen in Auth0 initially suggests (I found this out via the README.md file once I’d downloaded the sample).
- I modified the Program.cs file as follows to make it look like my code:
Added the call to .WithAccessToken(), set UseRefreshTokens to true, passed in my Api’s Audience value via a new config entry I added to appsettings.json
I also Added ClientSecret to .AddAuth0WebAppAuthentication() - because you need that to get an access token (also pulled from appsettings.json)
builder.Services.AddAuth0WebAppAuthentication(options =>
{
options.Domain = builder.Configuration["Auth0:Domain"];
options.ClientId = builder.Configuration["Auth0:ClientId"];
options.ClientSecret = builder.Configuration["Auth0:ClientSecret"];
options.Scope = "openid profile email";
})
.WithAccessToken(options =>
{
options.Audience = builder.Configuration["Auth0:Audience"];
options.UseRefreshTokens = true;
});
- Next I modified profile.razor to display the access and refresh tokens as well as the id token that the sample app code initially displays when you first download it:
@page "/Profile"
@inject TokenProvider tokenProvider
@attribute [Authorize]
<PageTitle>Profile</PageTitle>
<div class="row">
<div class="col-md-12">
<div class="row">
<h2>Profile</h2>
<div class="col-md-2">
<img src="@Picture"
alt="" class="img-rounded img-responsive" />
</div>
<div class="col-md-4">
<h3>@Username</h3>
<p>
<i class="bi bi-envelope"></i> @EmailAddress
</p>
<p>
<strong>Id Token</strong>: @IdToken
</p>
<p>
<strong>Access Token</strong>: @AccessToken
</p>
<p>
<strong>Refresh Token</strong>: @RefreshToken
</p>
</div>
</div>
</div>
</div>
@code {
[CascadingParameter]
public Task<AuthenticationState> AuthenticationStateTask { get; set; }
private string Username = "";
private string EmailAddress = "";
private string Picture = "";
private string IdToken = "";
private string AccessToken = "";
private string RefreshToken = "";
protected override async Task OnInitializedAsync()
{
var state = await AuthenticationStateTask;
Username = state.User.Identity.Name ?? string.Empty;
EmailAddress = state.User.Claims
.Where(c => c.Type.Equals(System.Security.Claims.ClaimTypes.Email))
.Select(c => c.Value)
.FirstOrDefault() ?? string.Empty;
Picture = state.User.Claims
.Where(c => c.Type.Equals("picture"))
.Select(c => c.Value)
.FirstOrDefault() ?? string.Empty;
IdToken = tokenProvider.IdToken;
AccessToken = tokenProvider.AccessToken;
RefreshToken = tokenProvider.RefreshToken;
await base.OnInitializedAsync();
}
}
- When I start my app, login with my user that has permissions, and inspect the resulting accessToken - I can see that it has an empty permissions array. This is just as it does when I access the exact same Regular Web Application using the same ClientId and ClientSecret from my code.
Here is an example of an access token I get (I’ve removed the secure details):
{
"iss": "https://{removed}.{removed}.auth0.com/",
"sub": "auth0|{removed}",
"aud": [
"https://cloudoko-portal-api/"
],
"iat": 1738191287,
"exp": 1738277687,
"scope": "openid profile email",
"org_id": "org_{removed}",
"azp": "{removed}",
"permissions": []
}
You can see the aud claim is as expected - so the SDK does seem to have passed my desired audience.
You can also see that permissions is an empty array - even though this user definitely has a role which grants it permissions to that API.
So my current conclusion is that either:
- There is an issue with my Regular Web application or API config in Auth0 - is it somehow corrupted (can that happen
)
(I am happy to share the details of it privately as it is in a dev tenant).
OR
- There’s something wrong with the .NET SDK code and the way it uses the settings from Program.cs to request that access token.
Hopefully you can follow my instructions from the earlier post and set a Regular Web Application up just like mine and break it too!?
Any suggestions where to go next?
Many thanks for your time!
Matt
Hey @matthew.wynn,
I followed the steps you described above, and I was able to get the expected permission in the permissions array. Honestly, I can’t find any reason you should not have the same result. I can only think of things like the following:
- Did you save the API settings when you enabled RBAC and “Add Permissions in the Access Token”?
- Are you sure that the user has the Reader role?
- Are you sure that the Reader role has the expected permission?
Sorry for the silly questions, but sometimes it happens that trivial things are missing…
Otherwise, I can’t find any other technical reason for this problem. Sorry.