From d1c92d3e6e91eafcf3a69177975aa855010e2213 Mon Sep 17 00:00:00 2001 From: Jiri Cincura Date: Thu, 25 Jun 2026 10:59:03 +0200 Subject: [PATCH 1/4] Improve documentation on role or user change during SignalR connection lifetime --- aspnetcore/signalr/authn-and-authz.md | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/aspnetcore/signalr/authn-and-authz.md b/aspnetcore/signalr/authn-and-authz.md index ecff776c7079..1a2f82deb375 100644 --- a/aspnetcore/signalr/authn-and-authz.md +++ b/aspnetcore/signalr/authn-and-authz.md @@ -28,6 +28,25 @@ The following code is an example that uses SignalR and ASP.NET Core authenticati > [!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. +### 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 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 In a browser-based app, cookie authentication allows existing user credentials to automatically flow to SignalR connections. When the browser client is used, no extra configuration is needed. If the user is signed in to an app, the SignalR connection automatically inherits this authentication. @@ -44,7 +63,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. From 1a499e1a8a04463d527c2311dded51b1b588bc66 Mon Sep 17 00:00:00 2001 From: Jiri Cincura Date: Thu, 25 Jun 2026 14:57:28 +0200 Subject: [PATCH 2/4] Update front matter. --- aspnetcore/signalr/authn-and-authz.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/aspnetcore/signalr/authn-and-authz.md b/aspnetcore/signalr/authn-and-authz.md index 1a2f82deb375..70ba19013416 100644 --- a/aspnetcore/signalr/authn-and-authz.md +++ b/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. From e90468db6f23bb5acddf0a8a1fe6803ff0f5ac17 Mon Sep 17 00:00:00 2001 From: Jiri Cincura Date: Thu, 25 Jun 2026 14:59:14 +0200 Subject: [PATCH 3/4] Unify ServerSentEvents name. --- aspnetcore/signalr/authn-and-authz.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/aspnetcore/signalr/authn-and-authz.md b/aspnetcore/signalr/authn-and-authz.md index 70ba19013416..77cd0d6d1dd7 100644 --- a/aspnetcore/signalr/authn-and-authz.md +++ b/aspnetcore/signalr/authn-and-authz.md @@ -27,7 +27,7 @@ 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 @@ -263,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 From 1ecdc33a11508b297d8485f55a26b9e724320908 Mon Sep 17 00:00:00 2001 From: Jiri Cincura Date: Fri, 26 Jun 2026 08:38:18 +0200 Subject: [PATCH 4/4] Feedback. --- aspnetcore/signalr/authn-and-authz.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/aspnetcore/signalr/authn-and-authz.md b/aspnetcore/signalr/authn-and-authz.md index 77cd0d6d1dd7..733fedc98497 100644 --- a/aspnetcore/signalr/authn-and-authz.md +++ b/aspnetcore/signalr/authn-and-authz.md @@ -6,7 +6,7 @@ description: Learn how to use authentication and authorization in your ASP.NET C monikerRange: '>= aspnetcore-3.1' ms.author: wpickett ms.custom: mvc -ms.date: 06/25/2026 +ms.date: 06/26/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. @@ -31,7 +31,7 @@ The following code is an example that uses SignalR and ASP.NET Core authenticati ### 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 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. +SignalR captures the authenticated user when a connection is established and caches it for the lifetime of the connection. The cached principal is exposed to hub methods through the `Context.User` 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. @@ -41,7 +41,7 @@ Consider the following scenario: * 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. +On the next long-poll request, the authentication middleware might authenticate the user without the `Editor` role (for example, if roles are loaded from a data store or the cookie is refreshed). However, the hub continues to authorize the user's `[Authorize(Roles = "Editor")]` hub method invocations because `Context.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: @@ -64,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. 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). +The client can provide an access token instead of using a cookie. The server validates the token and uses it to identify the user. For transports that make multiple HTTP requests (for example, `LongPolling` and `ServerSentEvents`), authentication runs on each request, but SignalR caches the resulting principal for the lifetime of the connection. As with cookie authentication, SignalR 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.