Improve documentation on role or user change during SignalR connection lifetime

aspnetcore/signalr/authn-and-authz.md

@@ -1,11 +1,12 @@
 ---
 title: SignalR authentication and authorization
+ai-usage: ai-assisted
 author: wadepickett
 description: Learn how to use authentication and authorization in your ASP.NET Core apps with SignalR, and compare the process for using cookies versus bearer tokens.
 monikerRange: '>= aspnetcore-3.1'
 ms.author: wpickett
 ms.custom: mvc
-ms.date: 05/20/2026
+ms.date: 06/25/2026
 uid: signalr/authn-and-authz
 
 # customer intent: As an ASP.NET developer, I want to use authentication and authorization in ASP.NET Core SignalR, so I can verify user access to my apps.
@@ -26,7 +27,26 @@ The following code is an example that uses SignalR and ASP.NET Core authenticati
 [!code-csharp[](authn-and-authz/6.0sample/SignalRAuthenticationSample/Program.cs?name=snippet1)]
 
 > [!NOTE]
-> If a token expires during the lifetime of a connection, by default the connection continues to work. `LongPolling` and `ServerSentEvent` connections fail on subsequent requests if they don't send new access tokens. For connections to close when the authentication token expires, set the [CloseOnAuthenticationExpiration](xref:signalr/configuration#configure-advanced-http-options) option.
+> If a token expires during the lifetime of a connection, by default the connection continues to work. `LongPolling` and `ServerSentEvents` connections fail on subsequent requests if they don't send new access tokens. For connections to close when the authentication token expires, set the [CloseOnAuthenticationExpiration](xref:signalr/configuration#configure-advanced-http-options) option.
+
+### User and role changes during the connection lifetime
+
+SignalR captures the authenticated user when a connection is established and caches it for the lifetime of the connection. The cached principal is exposed by the <xref:Microsoft.AspNetCore.SignalR.HubConnectionContext.User?displayProperty=nameWithType> property and is used to authorize hub method invocations. SignalR doesn't automatically revalidate the user during the life of the connection, regardless of the authentication scheme. This behavior applies to all schemes, including cookie authentication and bearer token authentication.
+
+Changes to a user's identity, roles, or claims that occur after the connection is established aren't reflected on an existing connection. This behavior applies even when the underlying transport makes new HTTP requests, such as the `LongPolling` and `ServerSentEvents` transports. Although the ASP.NET Core authentication middleware reauthenticates each of these HTTP requests, SignalR continues to use the principal that was cached when the connection was established.
+
+Consider the following scenario:
+
+* An app uses cookie authentication and the `LongPolling` transport. The same behavior applies to bearer token authentication and the `ServerSentEvents` transport.
+* A user is signed in with the `Editor` role and has an open SignalR connection.
+* The app removes the `Editor` role from that user.
+
+On the next long-poll request, the authentication middleware correctly authenticates the user without the `Editor` role. However, the hub continues to authorize the user's `[Authorize(Roles = "Editor")]` hub method invocations because `HubConnectionContext.User` still holds the principal that was cached before the role was removed. The user can keep calling `Editor`-only hub methods until the connection is closed.
+
+To enforce updated authorization on an active connection, take one of the following approaches:
+
+* Close affected connections so that clients reconnect and reauthenticate. For bearer token authentication, the [CloseOnAuthenticationExpiration](xref:signalr/configuration#configure-advanced-http-options) option closes connections when the authentication token expires.
+* Perform authorization checks in hub methods against current data, such as the user's current roles or claims from a data store, instead of relying only on the cached principal.
 
 ### Cookie authentication
 
@@ -44,7 +64,7 @@ Cookies are a browser-specific way to send access tokens, but nonbrowser clients
 
 ### Bearer token authentication
 
-The client can provide an access token instead of using a cookie. The server validates the token and uses it to identify the user. This validation is done only when the connection is established. During the life of the connection, the server doesn't automatically revalidate to check for token revocation.
+The client can provide an access token instead of using a cookie. The server validates the token and uses it to identify the user. This validation is done only when the connection is established. As with cookie authentication, the server doesn't automatically revalidate the user during the life of the connection to check for token revocation or for changes to the user's roles or claims. For more information, see [User and role changes during the connection lifetime](#user-and-role-changes-during-the-connection-lifetime).
 
 In the JavaScript client, the token can be provided by using the [accessTokenFactory](xref:signalr/configuration#configure-bearer-authentication) option.
 
@@ -243,7 +263,7 @@ public void Configure(IApplicationBuilder app)
 ```
 
 > [!NOTE]
-> If a token expires during the lifetime of a connection, the connection continues to work. `LongPolling` and `ServerSentEvent` connections fail on subsequent requests if they don't send new access tokens.
+> If a token expires during the lifetime of a connection, the connection continues to work. `LongPolling` and `ServerSentEvents` connections fail on subsequent requests if they don't send new access tokens.
 
 ### Cookie authentication