Blazor Web App with EntraID does not refresh auth after token expires

[Harl3]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I have a blazor web app with only interactive webassembly mode (prerendering disabled) secured with Entra ID as per https://learn.microsoft.com/en-us/aspnet/core/blazor/security/blazor-web-app-with-entra?view=aspnetcore-10.0&pivots=non-bff-pattern I'm using the NON bff pattern and without a downstream api.
My issue is that when the authentication token expires (default is roughly 1 hour) api calls just start giving errors with 301 found redirecting to the Entra login page. I would expect the auth state to refresh without giving errors.
My understanding is that Blazor wasm is not able to refresh auth state without a full page reload, so how should i handle this situation? Strangely i didn't find any documentation on this that i consider a pretty standard use case (maybe i didn't look well enough), so i guess i'm considering this a bug in the sample docs/app?
many thanks

Expected Behavior

Authentication state should gracefully refresh itself without backend api errors

Steps To Reproduce

Clone https://github.com/dotnet/blazor-samples/tree/main/10.0/BlazorWebAppEntra and run it.
login and then wait for the token to expire

Exceptions (if any)

No response

.NET Version

10.0.0

Anything else?

No response

[MihuBot]

I'm a bot. Here are possible related and/or duplicate issues (I may be wrong):

• MSAL on Blazor WebAssembly refresh token expiration invalid_grant regression #48264
• MSAL : Azure B2C Blazor wasm fails after 24 hours when the refresh token has been expired #48506

[Harl3]

the issues mentioned by the bot are not duplicates, as i'm using cookie auth in a blazorwebapp

[MackinnonBuck]

@jennyf19, will https://github.com/dotnet/blazor-samples/blob/d7a4b35dbb0193ec071fd6259e083b8b8a708484/9.0/BlazorWebAppEntraBff/BlazorWebAppEntra/Program.cs#L152 automatically refresh the auth token if it's expired?

[Harl3]

can anyone offer some guidance on this please? the issue persists in .net 10 and is blocking us from releasing

[MackinnonBuck]

@Harl3, you mentioned:

I have a blazor web app with only interactive webassembly mode (prerendering disabled)

But the sample you linked uses prerendering. Could you please clarify whether you're experiencing the issue in the untouched sample, or if the bug only occurs when you modify it to be interactive-only?

@guardrex, would you be able to try out the sample and see if there's an issue with it?

[guardrex]

Per @halter73's sample, it's configured with Interactive Auto rendering, and I hazard a guess that the built-in token refresh isn't going to work from the client under Interactive WebAssembly. Can we ask if @halter73 will comment? I can add a passing remark to the article on this subject depending on what he says. If I have to investigate myself, it will take time away from other high priority issues.

[halter73]

I'm using the NON bff pattern and without a downstream api.

@Harl3 As I'm sure you noticed, our "non-bff" sample does include MinimalApiJwt project which is the downstream API which should get the refreshed token via CallApiForUserAsync here in ServerWeatherForecaster. You'd be right to point out this is still following the BFF pattern despite claiming to be "non-BFF", but token refresh should work in this unmodified sample. We're working to update the "non-BFF" sample to not include a downstream API at all.

I wonder if you made any changes to the sample as part of removing the downstream API that also broke token refresh. How are you getting the token if not via CallApiForUserAsync? What API are you getting a 301 from if there's no downstream API? If you're using tokens, why are you getting a 301 redirect instead of a 401? Is it using cookies instead of tokens for the API calls resulting in a 301? Also, when you configured the application, was it for a confidential web application or a SPA? If you're using AddMicrosoftIdentityWebApp, the token never reaches the client, so it should be a confidential web application which has a token lifetime of well over 1 hour and shouldn't restrict the cookie lifetime to the token lifetime regardless.

Can you please provide a repro showing all the changes you made to the sample to remove the downstream API?

[Harl3]

Hi @halter73 , hi @MackinnonBuck, yes as i said i've removed the downstream api project from the sample as it was not needed for our application. we just have the server project and the wasm client project configured without prerendering and only with interactivewasm rendermode.
To remove the downstream api project we've just removed the project and remove the relevant configuration in the server's configuration. so my server's program.cs just looks like this:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorComponents()
    .AddInteractiveWebAssemblyComponents()
    .AddAuthenticationStateSerialization(options => options.SerializeAllClaims = true);

builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApp(options =>
    {
        builder.Configuration.Bind("AzureAd", options);
    })

var app = builder.Build();

app.MapRazorComponents<App>()
    .AddInteractiveWebAssemblyRenderMode()
    .AddAdditionalAssemblies(typeof(Nekte.Quantum365.Client._Imports).Assembly);

app.UseRouting();

app.UseAuthorization();

app.UseAntiforgery();

app.MapGroup("/authentication").MapLoginAndLogout();

The MapLoginAndLogout is the same extension method as in the sample.

The client's program.cs looks like this:

    var builder = WebAssemblyHostBuilder.CreateDefault(args);

    builder.Services.AddAuthorizationCore();

    builder.Services.AddCascadingAuthenticationState();
    builder.Services.AddAuthenticationStateDeserialization();

So the app should only be using a cookie to authenticate. and that works, the cookie gets correctly set, but as mentioned above after 1 hour api calls to the server's endpoint start to give 301 errors and in the api response i see a redirect to the entra login page. if i just F5, the auth gets refreshed and everything works again for another hour.

[MackinnonBuck]

@Harl3, is your app configured as a "web" application and not as a "single page" application? See https://learn.microsoft.com/entra/identity-platform/how-to-add-redirect-uri#add-a-redirect-uri for more information. This configuration can affect the token lifetime. Web applications get longer token lifetimes than SPAs because the token is never seen by the browser. See https://learn.microsoft.com/entra/identity-platform/refresh-tokens#token-lifetime