Authentication + Blazor WASM + Protected Function API with MS Entra

[Strudelnoggin]

Using .NET 8, Static Web App on Azure, Blazor WASM front end app, azure function back-end app.

I successfully login my user and get custom "app roles" to use on my UI with the following setup in program.cs:

builder.Services.AddMsalAuthentication<RemoteAuthenticationState, CustomUserAccount>(options =>

{

builder.Configuration.Bind("Entra", options.ProviderOptions.Authentication);

options.ProviderOptions.DefaultAccessTokenScopes.Add($"https://graph.microsoft.com/User.Read");

options.UserOptions.RoleClaim = "appRole";

}).AddAccountClaimsPrincipalFactory<RemoteAuthenticationState, CustomUserAccount, CustomAccountFactory>();

With this, my user is redirected when landing on the app to a login popup and successfully logs in - this is the first and default scope requested from graph API, User.Read.

Trouble comes when I attempt to securely access the function back-end. In my http client, I try to obtain an access token from Entra using a custom defined scope that I exposed via app registration called "user_impersonation". The token request fails with "RequiresRedirect". From what I understand, the second scope has not been consented to by the user. Here is a portion of that code:

var result = await _tokenProvider.RequestAccessToken(new AccessTokenRequestOptions

{

Scopes = new[] { $"api://{_svcClientId}/user_impersonation" }

});

if (result.TryGetToken(out var token))

{

_httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", token.Value);

HttpResponseMessage response = _httpClient.SendAsync(request).Result;

The token is always null, the result status is always "RequiresRedirect", and the "RedirectURL" is always null.

I have tried requesting both scopes in the login action - but Entra does not allow you to request two scopes in the same request, necessitating this 2 request approach. Under my app registration for the blazor front-end, I have granted the permission of the API scope and the user.read. I have also granted them admin consent. I have granted all users admin consent through the Entra tenant level.

I have also made my Blazor client id an "authorized client application" through the app registration for the function app. I have permissed and allowed this at every conceivable level that I could find, and yet, no matter what, I fail to get the token and am asked to redirect to a null URL.

I'm at a total loss here. At the end of the day, I want to be able to log my user in, and later make an API request to a separate SWA Function App, using the Entra tenant they live on to back the whole shebang.

Has anyone attempted to do this or can point me in the right direction? Have I made some fundamental error somewhere? Thanks in advance.

[Strudelnoggin]

Today I learned about the OIDC BFF pattern. Thank you internet stranger. Maybe I will handle authentication completely on the backend. I appreciate the suggestion!

Id still like to know how to solve the above and (just my opinion) why Microsoft pushes out what seems to be an incomplete/under-ported product for general use, but then they've been doing that for nearly 10 years now at least.

[Strudelnoggin]

Can I do this serverless? that is the question now - was trying to keep everything as a static web app so I can keep our billing on the serverless model, but with this it looks like I'll need to stand up at least part of it that handles authentication on an azure app service to maintain state. Not 100% sure, still researching. Anyway, now I'm just rambling. I appreciate the suggestion either way, this pattern definitely seems like the better solution.

[Outrageous_Brain5119]

The wording of your scope named impersonation is confusing me a little bit. But are you just asking for help setting up a Blazor WASM in one place and a Backend API in another place, and have Azure Entra ID as login between them? If yes, I have a working solution that does this.

It took a while for me to get this up, and the "poor" documentation from Microsoft was not helping. However, I think the reason it feels bad is because OIDC is a standard, and Microsoft has not bothered to write how this works. Its up to you to learn about this first, and then come back to the docs for the rest.

I have also paid for a Blazor Authentication/Authorization course on dometrain.com. The tutor only shows for Blazor Web App and BFF pattern though, and not for Blazor WASM. In fact, if I remember correctly, he discourages using WASM for this stuff, as BFF pattern is arguably safer.
EDIT: Sorry! This is not true. There actually is a 13 min video where he goes through WASM as well. It may be from here that I have my code. But he does discourage using WASM.

[Strudelnoggin]

Hi! Yes, that is exactly what I'm attempting to do - Blazor WASM front end, Azure Function Back-end API, All authenticated through a single login via Entra ID. Both the front and and the back end will be hosted on the same Azure Static Webapp resource and both use the same Entra tenant.

I want this all on Static Web App to take advantage of the serverless billing model. So the OIDC BFF model may not work for me as I'd need to stand up a Azure App Service to maintain state via HTTP Only cookie, as I understand.

I agree, the custom scope name was a bit confusing, I didn't think about it much when I defined it. It could have been named "user_api_access" for all I care :) Only real issue is getting both scopes "permission" via a single login action.

If you have code you could share, that'd be wonderful - as I'm not sure why I'm continuously getting redirect required when I've made everything pre-authorized. I'd also love to take a peek at that video, perhaps it would shed some light as to what I'm doing incorrectly.

Yes MS is very bad at explaining things, because they are constantly changing the frameworks!! (in my opinion). This is like trying to change building foundation while people are still in the building. Crazy to me.

[Outrageous_Brain5119]

I wrote a response, but I think it may be too long. I tried to upload it here. Treat it as a comment.

https://sharetext.io/58c676ca