Blazor Web Assembly authentication issue in version 10.0.8

Hi, just checking in. Do you have any update on this post?

@Danny Nguyen (WICLOUD CORPORATION) Replacing manually the AuthenticationService.js in 10.0.8 with the version from 10.0.7 works correctly with the 10.0.8 runtime, without any other changes. It looks like issue in the java script layer. Please share your thoughts on this. Thanks.

Thanks, that’s very helpful.

I also see this is already being tracked in https://github.com/dotnet/aspnetcore/issues/66978, and since you’re already on that issue, it’s probably best to continue tracking it there. If this turns out to be caused by an upstream/service-side/auth-stack change, that issue is the right place for the .NET team to coordinate investigation and any fix.

For now, sticking with the 10.0.7 AuthenticationService.js workaround seems reasonable until there’s more guidance or a fix on that issue.

Hi, just checking in—do you have any further questions about this issue? If the workaround works for you for now, I’d appreciate it if you can give me a confirmation.

Thank you.

Hi @Danny Nguyen (WICLOUD CORPORATION) Is it a valid approach or acceptable workaround to use AuthenticationService.js version 10.0.7 while running on runtime version 10.0.8? Would it be advisable to ship a production build that combines two different versions in this way? I would appreciate your thoughts on this.

Hi @Muthukumar S , thanks for the follow-up — this is a good question.

Using AuthenticationService.js from 10.0.7 with the 10.0.8 runtime can work as a temporary workaround, especially since you’ve already confirmed it restores the expected behavior. However, I wouldn’t consider this a long-term or ideal production setup, since it mixes assets across versions and may lead to unexpected issues later (especially if there are other changes in the auth pipeline).

If you plan to ship, a safer option would be to stay fully on 10.0.7 until there’s an official fix or guidance for 10.0.8.

If you notice any additional behavior differences or logs (especially around the login callback / JS execution), feel free to share — that may also help validate the root cause.
If there is no new updates, and these problem are already being tracked on https://github.com/dotnet/aspnetcore/issues/66978, I would greatly appreciate it if you could follow this guidance or provide feedback.

Thank you. 

Hi @Danny Nguyen (WICLOUD CORPORATION)

Here I am sharing my implementation configuration details, please have a look and let me know if you have any findings, Issues still exist even upgrading into the latest runtime 10.0.9 as well. but both 10.0.8 and 10.0.9 runtime, the auth flow is working fine with the AuthenticationService.Js version 10.0.7.

Note : RemoteUserAccount is null before sign-in and still null after the login callback completes

Program.cs

var builder = WebAssemblyHostBuilder.CreateDefault(args);

builder.RootComponents.Add<App>("#app");

builder.RootComponents.Add<HeadOutlet>("head::after");

// Boot order: pre-Blazor JS version gate → Blazor boot → MSAL token acquisition → ClaimFactory populates roles/permissions.

// MSAL authentication

builder.Services.AddMsalAuthentication(options =>

{

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

options.ProviderOptions.Cache.CacheLocation = "localStorage";

options.ProviderOptions.Authentication.ValidateAuthority = true;

options.ProviderOptions.LoginMode = "redirect";

})

.AddAccountClaimsPrincipalFactory<ClaimFactory>();

CliamFactory.cs

public class ClaimFactory(ILogger<ClaimFactory> logger,

  IHttpClientFactory httpClientFactory, 

  IAccessTokenProviderAccessor accessor, 

  NotificationService notificationService,

  IApplicationInsights applicationInsights,

  

  PermissionService permissionService) : AccountClaimsPrincipalFactory<RemoteUserAccount>(accessor)

{

  private readonly ILogger _logger = logger;

  private readonly IHttpClientFactory _httpClientFactory = httpClientFactory;

  private readonly PermissionService _permissionService = permissionService;

  private readonly IApplicationInsights _applicationInsights = applicationInsights;

  private readonly NotificationService _notificationService = notificationService;

  private readonly SemaphoreSlim _lock = new(1, 1);

  public override async ValueTask<ClaimsPrincipal> CreateUserAsync(RemoteUserAccount account, RemoteAuthenticationUserOptions options)

  {

      try

      {

          await _lock.WaitAsync();

          var user = await base.CreateUserAsync(account, options);

          if (user.Identity?.IsAuthenticated != true)

          {

              _logger.LogInformation("User is not authenticated. Skipping claims population.");

              return user;

          }

         

          var http = _httpClientFactory.CreateClient("Test.MyApp.API");

          var identity = (ClaimsIdentity)user.Identity;

         

         var roleTask = http.GetAsync("api/users/roles");

          var permissionTask = http.GetAsync("api/users/permissions");

          var isSuperAdminTask = http.GetAsync("api/users/superadmin");

          await Task.WhenAll(roleTask, permissionTask, isSuperAdminTask);

          var roleResponse = roleTask.Result;

          var userDto = roleResponse.StatusCode == HttpStatusCode.OK ? await roleTask.Result.Content.ReadFromJsonAsync<UserDto>() : new();

        

          var isSuperAdmin = await isSuperAdminTask.Result.Content.ReadFromJsonAsync<bool?>() ?? false;

          _permissionService.SetIsSuperAdmin(isSuperAdmin);

          var permissions = await permissionTask.Result.Content.ReadFromJsonAsync<HashSet<Permissions>>() ?? [];

          _permissionService.SetPermissions(permissions);

          List<string> newRoleClaims = [];

          foreach (var userRole in userDto.UserRoles.OrderBy(x => x.BusinessId))

          {

              switch (userRole.BusinessId)

              {

                  case "XXX":

                      identity.AddClaim(new Claim("XXX", userRole.Role));

                      newRoleClaims.Add($"XXXX_{userRole.Role}");

                      break;

                  case "YYY":

                      identity.AddClaim(new Claim("YYY", userRole.Role));

                      newRoleClaims.Add($"YYY_{userRole.Role}");

                      break;

                 

              }

              

          }

          var roleClaims = identity.FindAll(identity.RoleClaimType);

          if (roleClaims == null || roleClaims.Any() == false)

          {

              foreach (var roleClaim in newRoleClaims)

              {

                  identity.AddClaim(new Claim(identity.RoleClaimType, roleClaim));

              }

          }

          return user;

      }

      catch (AccessTokenNotAvailableException exception)

      {

          exception.Redirect();

          _logger.LogWarning("Access token not available. Redirecting to login.");

          return new ClaimsPrincipal();

      }

      catch (Exception ex)

      {

          _logger.LogError(ex, "Error obtaining user claims for My App.");

          throw;

      }

      finally

      {

          _lock.Release();

      }

  }

}

CsProj:

<ItemGroup>

<PackageReference Include="BlazorApplicationInsights" Version="3.3.0" />

<PackageReference Include="Blazored.FluentValidation" Version="2.2.0" />

<PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.23.0" />

<PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly" Version="10.0.8" />

<PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.DevServer" Version="10.0.8" PrivateAssets="all" />

<PackageReference Include="Microsoft.Authentication.WebAssembly.Msal" Version="10.0.8" />

<PackageReference Include="OpenTelemetry.Api" Version="1.15.3" />

<PackageReference Include="Telerik.UI.for.Blazor" Version="12.3.0" />

</ItemGroup>

Hi @Muthukumar S , thanks for sharing the details.

From the code you shared, I don’t see anything obvious in the ClaimFactory that would explain why RemoteUserAccount stays null after the login callback. Since replacing only AuthenticationService.js with the 10.0.7 version restores the auth flow, this still points more toward a JavaScript auth layer change/regression.

One thing I noticed is that your .csproj still references 10.0.8 packages. If you are testing 10.0.9, please make sure these package references are also updated to 10.0.9, then clean bin / obj, clear browser cache/site data, and test again with matching 10.0.9 files.

That said, I would not recommend using mixed versions, such as 10.0.7 AuthenticationService.js with 10.0.8/10.0.9 runtime, as a long-term production solution. It may be okay only as a temporary workaround for validation. The safer option is to stay fully on the working 10.0.7 set until there is official guidance or a fix.

Since this appears related to the GitHub issue already being tracked here: aspnetcore issue 66978, I’d suggest adding your latest findings there too, especially that 10.0.8 and 10.0.9 both reproduce the issue, and replacing only AuthenticationService.js with 10.0.7 restores the auth flow.

One thing I noticed is that your .csproj still references 10.0.8 packages Hi @Danny Nguyen (WICLOUD CORPORATION) The issue still remains the same in both 10.0.8 and 10.0.9, If it is an issue with the javascript layer, how do we address this issue? Also one more observation AuthenticationServices.js is identical on both 10.0.8 and 10.0.9.