Regression, Blazor WASM OIDC login callback to not sent to the requested page when published

[aguacongas]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I opened this issue #44973 for .Net 7 and it's occurs again for .Net 8 RC2

On login callback, the requested protected page should be display if the user has authorization. It was the case with .Net 6

Expected Behavior

The requested protected page should be display if the user has authorization

Steps To Reproduce

Using the code in the repo aguacongas/BlazorAuthIssue. It's a simple blazor wasm starter with OIDC authentication.

publish the server dotnet publish -c Release
Launch the published server with .\BlazorAuthIssue.Server.exe --urls http://localhost:5001
Click on Counter
Login with alice, pwd: Pass123$
The index page is displayed but the counter page should be displayed

Exceptions (if any)

No response

.NET Version

8.0.100-rc.2.23502.2

Anything else?

No response

[aguacongas]

Note also that logout stay stuck on Processing logout callback...

[sslaws]

Adding workaround described by #45028 but removing the reference to Microsoft.Authentication.WebAssembly.Msal resolved the Processing logout callback... issue.

[halter73]

The requested protected page should be display if the user has authorization

This is due to a documented breaking change in .NET 7 https://learn.microsoft.com/en-us/dotnet/core/compatibility/aspnet-core/7.0/wasm-app-authentication. tl;dr:

--- a/Client/Shared/RedirectToLogin.razor
+++ b/Client/Shared/RedirectToLogin.razor
@@ -1,8 +1,10 @@
-@inject NavigationManager Navigation
+@using Microsoft.AspNetCore.Components.WebAssembly.Authentication
+
+@inject NavigationManager Navigation
 
 @code {
     protected override void OnInitialized()
     {
-        Navigation.NavigateTo($"authentication/login?returnUrl={Uri.EscapeDataString(Navigation.Uri)}");
+        Navigation.NavigateToLogin($"authentication/login");
     }
 }

Note also that logout stay stuck on Processing logout callback...

This is a trimming bug. It should be fixed by #54225 which we plan to backport for 8.0.x servicing.