.NET 7 Blazor WASM authentication back button history behavior still problematic with 3rd party IDP

Summary

.NET 7 improved Blazor WASM’s authentication back history behavior in pull #43954. The underlying issue was described in issue #43063 @javiercn

However, after testing the new implementation, I’m still not getting the desirable behavior: back button returns to previous page that does not require authentication.

Motivation and goals

Consider the following typical scenario:

1. User is currently on contoso.com, an unprotected Blazor home page.
2. User clicks a link on the page, contoso.com/protected, which is a protected Blazor page via @attribute [Authorize]
3. The app.razor sees that this is a protected route, and redirects user to contoso.com/Authentication/login via the RedirectToLogin Blazor component.
4. The authentication component in turn redirects the user to a 3rd party IDP login page, such as AAD B2C’s contoso.b2clogin.com.
5. Now user realizes this is a protected area, but decides not to sign up or login, and presses the back button, with the intent to go back to the unprotected contoso.com home page.

However, in reality, the back button brings the user to contoso.com/protected, which then redirects the user to /Authentication/login and finally the IDP login page again, still resulting in a loop.

I believe this is a bit better than the previous version, where the back button would bring the user to /Authentication/login which would trigger a failure message.

But I think it would be a much better experience if the new history state manager can store the URL the user was on before the protected page was requested that triggered authentication, and bring the user to that page accordingly when back button is clicked.

[javiercn]

The remaining work here is to add an overload that takes a boolean we apply to ReplaceHistoryEntry

[javiercn]

The only difference with the code you showed me was to add the ReplaceHistoryEntry = true, right? This part confused me because I thought #43954 mentioned history is replaced by default in the new version, but now I guess that was referring to to the internal implementation of the authentication JS?

Yep.

I personally think the final behavior I proposed and you helped me achieve here should be the “ideal” default, out-of-the-box behavior for most use cases (avoiding authentication loop via back button press), that could warrant a documentation/default code update. What do you think?

I would be ok if we add this option to the helper methods, but I do not think is the correct default. That works when some part of your app does not require auth, but it does not when all your app requires authorization.