When can Task<AuthenticationState> be null in Blazor Server?

[UniMichael]

In Blazor Server, if I use builder.services.AddCascadingAuthenticationState(), will the Task<AuthenticationState>? cascading parameter ever actually be null?

I'm asking because I'm working on a multi-tenant application, and most pages need to fetch data based on the user's claims. Because of the null check, I end up using OnParametersSetAsync with comparisons a lot, when I would prefer to just load the data in OnInitializedAsync and be done with it.

Looking at the AspNetCore source code, it seems like the default AuthenticationStateProvider implementations all seem to have a non-null value.

[Junaid-PK]

With AddCascadingAuthenticationState() registered, the value should not be null by the time OnInitialized{Async} runs.

The registration creates a CascadingValue<Task<AuthenticationState>> whose value comes from AuthenticationStateProvider.GetAuthenticationStateAsync() (source). That provider method has a non-nullable return contract, and authentication-state change notifications reject a null task (source). Component parameters, including cascading parameters, are assigned before OnInitialized/OnInitializedAsync is called (ComponentBase.SetParametersAsync).

So this is reasonable when the cascade is guaranteed by the application:

@code {
    [CascadingParameter]
    private Task<AuthenticationState> AuthenticationStateTask { get; set; } = default!;

    protected override async Task OnInitializedAsync()
    {
        var state = await AuthenticationStateTask;
        await LoadForTenantAsync(GetTenantId(state.User));
    }
}

The nullable annotation commonly seen in framework components represents the case where there is no matching cascade. It is not an indication that the registered provider normally supplies a null task. A custom provider returning null would also be violating the API contract. A missing AuthenticationStateProvider registration fails while resolving the required service rather than producing a null cascade.

There is a separate reason you may still need OnParametersSetAsync: authentication state is allowed to change during the component lifetime. The cascading-value source is explicitly not fixed and subscribes to AuthenticationStateChanged, forwarding a new task to consumers (same source, lines 29–54). Login, logout, or revalidation can therefore make the tenant claim change without recreating the component.

In short:

• If tenant identity is guaranteed to remain fixed for this component/circuit, load once in OnInitializedAsync; default! expresses that the app guarantees the cascade.
• If the provider can notify authentication changes, keep the tenant-ID comparison in OnParametersSetAsync. That comparison is protecting against a changed value, not against a normally null task.