GetAuthenticationStateAsync() should not be called automatically on [AllowAnonymous] pages

[mckaragoz]

Summary

Currently, the AuthenticationStateProvider.GetAuthenticationStateAsync() method is invoked automatically on all pages, including those marked with [AllowAnonymous]. This leads to unnecessary token validations and refresh attempts even on pages that don't require authentication. This results in performance overhead, unwanted UI states like "Authorizing...", and possible JS interop issues during static rendering.

Proposal:

Provide a built-in way to skip or delay the GetAuthenticationStateAsync() call for anonymous pages, or allow developers to control when and where the authentication state is evaluated.

[halter73]

Thanks for the report. Out of curiosity, are you using an AuthenticationStateProvider that we provide or something custom? It's generally acceptable to have GetAuthenticationStateAsync return an anonymous user immediately if there's no user data already stored, so I'm not sure why there would be an unwanted "Authorizing..." state.

and possible JS interop issues during static rendering.

I think this might be the fundemantal problem. It's impossible to authenticate during prerendering if authentication requires JS interop. At this point, we haven't even delivered JS to the browser yet. Can you please provide your AuthenticationStateProvider code and how it's wired up?

[mckaragoz]

Let me explain further. I use custom AuthenticationStateProvider, but the issue is not about the authenticated user data or the custom component. I'm questioning the working system of the component (the default behavior). The GetAuthenticationStateAsync is called directly when a page load. But it doesn't look at the page attributes. An example GetAuthenticationStateAsync even run on the pages that is anonymous and doesn't have any AuthorizeView inside. It means we validate tokens even on anonymous page initialized. This behavior uses system resources unnecessarily. I think GetAuthenticationStateAsync should be called only if it's exactly necessary (users can call manually if they need on anonymous pages.)

[MackinnonBuck]

Thanks for reaching out. This behavior is by design. We still want to populate information about the user even on pages that are marked with [AllowAnonymous]. For performance reasons, it's okay to return an unauthorized user if no authorized user is cached, and use AuthorizeRouteView to handle the more expensive logging in of an uncached user.