Blazor Server: Detect and prevent silent user identity changes on SignalR circuit reconnect

[KurtP20]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Describe the problem
In a Blazor Server app with cookie-based authentication (e.g., ASP.NET Core Identity), the HTTP auth cookie is shared across browser tabs. When the user logs out and logs in as a different user in one tab, the cookie is updated accordingly. However, existing SignalR circuits in other tabs can reconnect silently using the updated cookie, leading to the circuit executing under a new identity without any user interaction, notification, or explicit check.

This can occur during normal SignalR reconnection scenarios (e.g., network hiccups, transient disconnects), where the client attempts to reconnect and the server rebinds the circuit using the current cookie principal. The framework does not enforce an invariant that the identity at reconnect matches the identity at circuit creation. As a result, a previously authenticated tab can suddenly start executing under a different authenticated principal, which can lead to cross-user contamination, security boundary violations, and unsafe user state.

Why this is an issue

• Blazor Server circuits are stateful and assume continuity of user context.
• Shared authentication cookies (standard browser behavior) mean multiple tabs can influence the same session.
• Silent reconnect (SignalR automatic reconnect) does not provide a hook or safety check to detect identity changes.
• There is currently no built-in mechanism to detect or reject a reconnect when the authenticated user principal has changed.

Existing issues have discussed cookie changes and reconnection behavior (e.g., auth state not reacting to cookie changes) but do not explicitly address detection or prevention of identity changes on reconnect (see related issues like #50858 which focuses on auth state hydration, not SignalR identity invariants).

Expected behavior
Framework support (opt-in or default) for one or more of the following:

1. Hard fail on circuit reconnect if the authenticated principal has changed since circuit creation.
2. A reconnect identity change event/callback so apps can observe and handle it.
3. A configurable policy (e.g., CircuitIdentityPolicy.RequireStablePrincipalOnReconnect) that enforces user identity stability.
4. Clear documentation/stabilization of behavior when authentication cookies change during an active Blazor Server session.

Impact
Without such checks, apps - especially enterprise apps - must implement ad-hoc workarounds (e.g., capturing a stable user key and validating it on every component/service invocation), which is error-prone and not centrally enforced.

Steps to reproduce (conceptual)

1. Blazor Server app with cookie authentication (ASP.NET Core Identity).
2. Open Tab A, authenticate as UserA.
3. Open Tab B, authenticate as UserB.
4. Cause a transient disconnect (e.g., blocking network momentarily).
5. Allow automatic reconnect to occur in Tab A’s circuit.
6. Observe that Tab A’s circuit now runs under UserB silently, with no UI update.

Describe the solution you'd like

Guarantee identity continuity for a Blazor Server circuit. If a circuit was created under UserA, it must never continue executing under UserB after a reconnect unless the app explicitly allows it.

When a Blazor Server circuit is established:

1. Snapshot a stable user identifier from the initial HttpContext.User, e.g.: ClaimTypes.NameIdentifier
2. On any reconnect / rebind, compare the current HttpContext.User stable id to the circuit’s snapshot.
3. If it differs:
   • reject the reconnect (do not attach to the existing circuit), and
   • terminate the circuit (or force a hard reload / re-auth).

This prevents cross-user contamination by construction.

Additional context

No response

[MackinnonBuck]

Describe the solution you'd like:
reject the reconnect... and terminate the circuit

This seems reasonable. An alternative might be to keep the circuit but guarantee that components got correctly disposed and reinitialized when the user identity changes, and we'd also fire the AuthenticationStateChanged event.

[MackinnonBuck]

When we reproduced this, we noticed that stale values from statically rendered components might still be rendered on the page even after interactive components on the same page re-render. This is strange for the user but shouldn't create cross-user contamination as the SSR'd components no longer exist on the server at that point. Might this be what happens in your testing? Or are you observing that interactive components don't get disposed and re-initialized when the user identity changes?

[MackinnonBuck]

We were able to create a repro that demonstrates an interactive component instance persisting across user identity changes after reconnection. Components do re-render and receive the updated cascading authentication state, but this doesn't help if the component fetched and cached state about the "current" user in OnInitializedAsync() without any logic for invalidating that state due to user identity changes. The correct way to handle this today would be ensuring that component logic correctly handles identity user changes in OnAfterRenderAsync() (or in a handler for the AuthenticationStateChanged event). But we should consider providing a way to make this more automatic, such as starting a new circuit or re-initializing the entire component hierarchy under AuthorizeRouteView.

[KurtP20]

Hi, thanks for looking into this.

This is not about stale SSR output. I agree that statically rendered components lingering client-side is primarily a UX issue and does not cause cross-user contamination once the circuit is gone.

The concern is specifically about interactive circuits reconnecting under a different authenticated user without an explicit circuit reset or notification that forces the app to invalidate its state.

Disposal and re-initialization alone are not sufficient guarantees. During reconnect there is a critical window where:

• the circuit is still alive,
• scoped services are still alive,
• UI events (SignalR messages) can still arrive,
• and application code may execute before disposal or re-initialization occurs.

If the reconnect logic can associate an existing circuit with a different ClaimsPrincipal, an important invariant is broken: A Blazor Server circuit implicitly assumes a stable user identity for its lifetime.

Once this invariant is broken, any cached user-derived state becomes unsafe, even if components later re-render. This enables the following class of bug:

• User A interacts with Tab A.
• Authentication changes elsewhere (logout/login, cookie overwrite, etc.).
• The circuit reconnects and is now associated with User B.
• A pending or subsequent UI event from Tab A is processed and persisted under User B.

From the application’s perspective this is silent cross-user attribution, even if the UI eventually reflects the new user.

I agree with your observation that components caching user data in OnInitializedAsync must invalidate that state if identity can change under the same circuit. However, relying on AuthenticationStateChanged or OnAfterRenderAsync is not a complete mitigation for the reconnect scenario:

• AuthenticationStateChanged is circuit-scoped and does not fire when authentication changes in a different circuit/session and the existing circuit reconnects under a different principal.
• After reconnect, the component only sees “the current auth state”, which may already represent a different user, unless the app explicitly tracks and compares a prior identity.

For this reason, I added an explicit per-circuit identity guard (EnsureSameUserAsync) that stores an identity key at initialization and rejects operations if the current principal differs. This prevents silent cross-user attribution but feels like compensating for a missing framework-level guarantee.

I can’t provide a minimal deterministic repro (the issue is timing- and environment-dependent), but it’s great that you have one demonstrating component persistence across identity changes after reconnect.

I agree with your direction. From an application-developer perspective, it would be much safer if the framework either:

• guaranteed that a circuit can never be rebound to a different authenticated identity, or
• detected identity changes during reconnect and forcefully tore down/restarted the circuit (and ideally the component subtree under AuthorizeRouteView), combined with an auth-state notification.

Anything weaker forces every stateful Blazor Server app to independently rediscover and defend this invariant.

[MackinnonBuck]

If the reconnect logic can associate an existing circuit with a different ClaimsPrincipal, an important invariant is broken: A Blazor Server circuit implicitly assumes a stable user identity for its lifetime.

That's not necessarily true, as you can log out and log in to a different account without creating a new circuit.

However, I could see it being useful to have an option to completely dispose and re-initialize the circuit when the user changes. We probably wouldn't do that by default because it would be breaking, but it would be convenient to have an opt-in mechanism that eliminates the need to handle user identity changes on a case-by-case basis.

cc @javiercn - do you think this is a reasonable direction?

[KurtP20]

Hi -an opt-in “dispose and recreate circuit on identity change” mechanism would be very valuable, and it would prevent cross-contamination of scoped state when a circuit is resumed under a different user.

One clarification I think is important from an application/UX perspective: disposing the circuit addresses state safety, but it does not necessarily make a user switch observable to the end user.

If the circuit is disposed and the client simply reconnects or reloads the same route under the new authentication cookie, the page may look identical while now running under a different user. That is no longer dangerous in terms of server-side state, but it can still be surprising or misleading from a user’s point of view and apps need a way to prevent this.

Therefore, a dedicated hook or signal when an identity change triggers circuit disposal (distinct from normal disconnects) seems essential, so apps can redirect to a neutral page or show “session changed”. With such a hook, I don’t particularly care whether the circuit is disposed automatically or how the reconnect is implemented.

Enforcing “no circuit resumes under a different principal” might break some apps, but it’s the security-hardening kind of break. Making it opt-in in the beginning followed by a staged rollout might be a viable option.

[javiercn]

Hi @KurtP20, thank you for the detailed feedback on this topic.

We'd like to clarify a few points:

If the reconnect logic can associate an existing circuit with a different ClaimsPrincipal, an important invariant is broken: A Blazor Server circuit implicitly assumes a stable user identity for its lifetime.

This isn't accurate, and it's not a guarantee that Blazor Server provides. We intentionally recompute identity on each reconnection as a security measure. Your app is responsible for observing and reacting to authentication state changes during reconnection.

This behavior is consistent with standard web authentication patterns. Consider a user holding a cookie or a JWT where the authentication server has invalidated the session tokens that are self-asserting (meaning they aren't pointers to a database row that tracks their validity) will naturally have this characteristic. Blazor Server behaves similarly: we re-evaluate the user's credentials on reconnection.

The concern is specifically about interactive circuits reconnecting under a different authenticated user without an explicit circuit reset or notification that forces the app to invalidate its state.

The AuthenticationStateProvider is the mechanism we provide for exactly this purpose, notifying any component or service on the circuit of authentication state changes. The documentation covers how to subscribe to AuthenticationStateChanged and handle user changes appropriately.

Additionally, the CircuitHandler.OnConnectionUpAsync method is called every time the circuit reconnects, which provides another hook for detecting and responding to identity changes.

We already provide mechanisms for observing authentication state changes, and it's the developer's responsibility to use them based on their app's requirements.

The main case where this can happen is when you are directly using AuthenticationStateProvider which is not common since we provide dedicated components to handle this correctly (AuthorizeView, CascadingAuthenticationValue).

Based on this, we don't think adding a framework-level feature that automatically rejects reconnections or terminates circuits on identity change is the right approach, and especially not as a default behavior.

The scenario that you bring up is covered in the docs and something we provide explicit guidance about. The underlying cause is an issue in failing to invalidate cache against auth changes, and that can happen in many situations beyond reconnection, so even if it helped, it wouldn't solve the problem, and it would provide a false sense of security.

I've filed #65337 to propose an enhancement to provide an analyzer to detect incorrect usages, but if you are writing your own auth code (using AuthenticationStateProvider) you are responsible for using it correctly. The framework already provides built-in primitives to handle this correctly.

There are also a couple of approaches you can take yourself in the app to implement the behavior you want.

Option 1: Use @key to force component tree recreation

You can wrap your Router or AuthorizeRouteView with a @key directive based on the user's identity (e.g., the NameIdentifier claim). When the @key value changes, Blazor discards the entire subtree and rebuilds it with new component instances, effectively reinitializing all components.

@inject AuthenticationStateProvider AuthStateProvider

<Router AppAssembly="typeof(App).Assembly" @key="@_userKey">
    <!-- ... -->
</Router>

@code {
    private string? _userKey;

    protected override async Task OnInitializedAsync()
    {
        AuthStateProvider.AuthenticationStateChanged += OnAuthStateChanged;
        await UpdateUserKey();
    }

    private async void OnAuthStateChanged(Task<AuthenticationState> task)
    {
        await UpdateUserKey();
        await InvokeAsync(StateHasChanged);
    }

    private async Task UpdateUserKey()
    {
        var authState = await AuthStateProvider.GetAuthenticationStateAsync();
        _userKey = authState.User.FindFirst(ClaimTypes.NameIdentifier)?.Value 
                   ?? Guid.NewGuid().ToString();
    }
}

Option 2: Force a full page reload on reconnection

In your CircuitHandler.OnConnectionUpAsync, you can detect identity changes and trigger a full page reload via JS interop:

public override async Task OnConnectionUpAsync(Circuit circuit, 
    CancellationToken cancellationToken)
{
    var newState = await _authStateProvider.GetAuthenticationStateAsync();
    var newUserId = newState.User.FindFirst(ClaimTypes.NameIdentifier)?.Value;

    if (_previousUserId != null && _previousUserId != newUserId)
    {
        // User changed - force full page reload
        await _jsRuntime.InvokeVoidAsync("location.reload");
    }

    _previousUserId = newUserId;
}

[KurtP20]

Hi @javiercn , thanks for the detailed response and the concrete examples, that helps clarify the current stance.

I understand that Blazor Server intentionally recomputes identity on reconnection and that reacting to authentication state changes is considered the application's responsibility. I also agree that identity changes can happen outside reconnection and therefore apps must generally handle them.

However, the concern I’m raising is slightly different: it’s not about authentication correctness, but about having a central, reliable lifecycle point when an interactive circuit continues under a different authenticated principal.

Today the available primitives are:

• AuthenticationStateChanged
• CircuitHandler.OnConnectionUpAsync
• component-level patterns (AuthorizeView, @key, etc.)

But none of these provide a single deterministic place to enforce a policy like:
“If this circuit resumes under a different user, terminate the session and show a dedicated ‘session changed’ page.”

In practice:

• AuthenticationStateChanged is scoped to the current circuit and won’t fire if the auth change happens in another tab until reconnection occurs.
• reacting at the component level requires defensive checks throughout the app.
• OnConnectionUpAsync runs after reconnection and is not designed as a synchronous gate before the circuit continues execution.

So while the framework provides the building blocks, there is currently no centralized callback that guarantees:

• identity mismatch detected,
• before normal app execution continues,
• allowing the app to terminate or redirect deterministically.

The goal is not to invalidate render trees or rebuild components under a new identity.
The goal is to explicitly end the interactive session and transition to a neutral state when the principal changes.

Without a central hook, the only safe option is to guard every critical code path against identity drift, which is difficult to enforce and easy to miss in larger applications.

So the request is not for the framework to enforce identity stability or reject reconnections by default, but rather:

• provide a first-class, centralized callback/hook when a circuit reconnects under a different principal,
• ideally early enough to allow apps to terminate or redirect before normal execution resumes.

This would not replace the existing primitives, but it would provide a reliable enforcement point for applications that require strict session continuity semantics.

The analyzer proposal sounds useful, but it addresses usage patterns rather than providing a runtime lifecycle guarantee.

[javiercn]

Hi @KurtP20, thanks for the additional details.

There are a few ways to have a single, centralized, deterministic hook that runs before normal circuit execution resumes after a reconnect. Here are two samples:

Option 1: CircuitHandler.CreateInboundActivityHandler (recommended)

This is probably the closest thing to what you're describing. CreateInboundActivityHandler lets you create a handler that intercepts every inbound activity dispatched on the circuit, including the activity that occurs when a circuit reconnects and the client starts sending messages again. It works as an async middleware-style pipeline: your code runs before next is invoked, giving you a gate before any application logic executes on the circuit.

Here's a complete example that captures the user identity when the circuit opens and rejects all subsequent inbound activity if the identity changes:

using System.Security.Claims;
using Microsoft.AspNetCore.Components.Authorization;
using Microsoft.AspNetCore.Components.Server.Circuits;

public class IdentityGuardCircuitHandler : CircuitHandler
{
    private readonly AuthenticationStateProvider _authStateProvider;
    private string? _initialUserId;

    public IdentityGuardCircuitHandler(AuthenticationStateProvider authStateProvider)
    {
        _authStateProvider = authStateProvider;
    }

    public override async Task OnCircuitOpenedAsync(Circuit circuit, CancellationToken cancellationToken)
    {
        // Capture the user identity when the circuit is first established.
        var authState = await _authStateProvider.GetAuthenticationStateAsync();
        _initialUserId = authState.User.FindFirst(ClaimTypes.NameIdentifier)?.Value;
    }

    public override Func<CircuitInboundActivityContext, Task> CreateInboundActivityHandler(
        Func<CircuitInboundActivityContext, Task> next)
    {
        return async context =>
        {
            // This runs before every inbound activity on the circuit,
            // including after a reconnect. We check the current identity
            // and reject the activity if it has changed.
            var authState = await _authStateProvider.GetAuthenticationStateAsync();
            var currentUserId = authState.User.FindFirst(ClaimTypes.NameIdentifier)?.Value;

            if (_initialUserId is not null && currentUserId != _initialUserId)
            {
                // Identity has changed. Throw to prevent the circuit
                // from continuing execution under a different user.
                throw new InvalidOperationException(
                    "The authenticated user identity has changed. " +
                    "This circuit will be terminated for security.");
            }

            // Identity matches. Allow the activity to proceed.
            await next(context);
        };
    }
}

Register it in your Program.cs:

builder.Services.AddScoped<CircuitHandler, IdentityGuardCircuitHandler>();

This gives you the centralized, pre-execution gate you asked for. No inbound activity on the circuit (render batches, event dispatches, JS interop calls) will execute until your handler allows it through.

Option 2: SignalR Hub Filter (IHubFilter)

If you'd prefer to operate at the SignalR transport level instead, which can be useful if you want to guard all hub method invocations, not just Blazor circuit activity, you can use a SignalR hub filter. Hub filters run before and after every hub method invocation, including the ones Blazor uses internally. You can use OnConnectedAsync in the filter to capture the initial identity and InvokeMethodAsync to guard every subsequent call:

using Microsoft.AspNetCore.SignalR;
using System.Security.Claims;

public class IdentityGuardHubFilter : IHubFilter
{
    // We use a static dictionary keyed by connection ID for simplicity.
    // In production, consider a scoped or per-connection approach.
    private static readonly Dictionary<string, string?> _initialIdentities = new();

    public async Task OnConnectedAsync(
        HubLifetimeContext context,
        Func<HubLifetimeContext, Task> next)
    {
        // Capture the identity when the connection is first established.
        var userId = context.Context.User?.FindFirst(ClaimTypes.NameIdentifier)?.Value;
        _initialIdentities[context.Context.ConnectionId] = userId;

        await next(context);
    }

    public async ValueTask<object?> InvokeMethodAsync(
        HubInvocationContext invocationContext,
        Func<HubInvocationContext, ValueTask<object?>> next)
    {
        var connectionId = invocationContext.Context.ConnectionId;
        var currentUserId = invocationContext.Context.User?
            .FindFirst(ClaimTypes.NameIdentifier)?.Value;

        if (_initialIdentities.TryGetValue(connectionId, out var initialUserId)
            && initialUserId is not null
            && currentUserId != initialUserId)
        {
            throw new HubException(
                "The authenticated user identity has changed since the connection " +
                "was established. This connection will be terminated for security.");
        }

        return await next(invocationContext);
    }

    public async Task OnDisconnectedAsync(
        HubLifetimeContext context,
        Exception? exception,
        Func<HubLifetimeContext, Exception?, Task> next)
    {
        // Clean up stored identity when the connection is closed.
        _initialIdentities.Remove(context.Context.ConnectionId);
        await next(context, exception);
    }
}

Register it in Program.cs. Since Blazor Web Apps wire up the server-side circuit hub through MapRazorComponents, you configure the hub filter on the interactive server render mode options:

builder.Services.AddSingleton<IdentityGuardHubFilter>();

// ...

app.MapRazorComponents<App>()
    .AddInteractiveServerRenderMode(options =>
    {
        options.AddFilter<IdentityGuardHubFilter>();
    });