Changing access token during SignalR session (with websockets protocol)

[simeyla]

The following phrase is emphasized on https://docs.microsoft.com/en-us/aspnet/core/signalr/authn-and-authz?view=aspnetcore-2.2:

The access token function you provide is called before every HTTP request made by SignalR. If you need to renew the token in order to keep the connection active (because it may expire during the connection), do so from within this function and return the updated token.

However it's easy to confuse 'http request' here with the concept of 'message sent'.

When using websockets there is only one http request made when you first connect - after that the token isn't sent again and my function isn't called. The above paragraph kind of implies it will automagically refresh itself when it changes which for websockets isn't entirely accurate.

Can you make it clearer what the recommended procedure is for changing access token when connected with websockets. I assume I'm supposed to just disconnect and reconnect.

Although to be frank this is kind of a massive pain and I'm almost tempted to just send the access token as part of the message (which in my case is rarely needed anyway).

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: d0da2144-3730-f8ef-1d16-a89f11fd6198
• Version Independent ID: 6d8f5bc8-8f5c-ba13-b7f2-0366eac46f81
• Content: Authentication and authorization in ASP.NET Core SignalR
• Content Source: aspnetcore/signalr/authn-and-authz.md
• Product: aspnet-core
• Technology: aspnetcore-signalr
• GitHub Login: @bradygaster
• Microsoft Alias: bradyg

[mmulhearn]

1 million times this. I'm bashing my head against the desk wondering why my accessTokenFactory method isn't being called once the connection is established, wondering if I'm doing something wrong. This note is completely misleading and should be removed. What is MSFT's recommended approach? Is it in fact to disconnect and reconnect when a new access token is received? This seems like a massive oversight.

[calhamdower]

+1 here also. Very confusing.
I've also found that the Authorize attribute doesnt really protect you from expired tokens also.
dotnet/aspnetcore#5283
So with Websockets, once you set up a connection.. on the client side you're not easily able to keep your tokens up to date: and then on the server side: it doesn't check if they're expired anyway...

[darkpq]

tl;dr: Does using a pattern of establishing/reestablishing websocket-based connections to a hub on an as-needed basis create too much connection overhead (or defeat the purpose of web-sockets to begin with) to be useful as a solution to the above problems? (The idea being that each re-established connection would use a token re-fresh pattern)

Story:
I'm currently trying to write a live multi-user app using Blazor client-side with a feature-rich server-side using signalr. I have signalr connections working and token validation working with all of the above issues with authorization (tokens only validated on connection, and web-socket calls to hub methods are 'authorized' with expired tokens indefinitely on the same connection as was established when the token was valid. Re-connection attempts fail authorization with an expired token).

All that said, if I'm going to stick with jwt auth, is it just better to use a short expiry and a refresh token pattern, with a policy that between client-side actions that don't occur frequently enough connections are dropped, as a solution as opposed to having to have "timed tasks" on both the client side and server side? (Those tasks being what causes expired tokens to be re-issued?)

[Tommigun1980]

Microsoft, what is your guidance regarding expiring tokens both on the client and the server?

[kherona]

This would cause a lot of errors goes undetected. I am hoping that someone can provide a viable solution or workaround.

[kherona]

Here is another request about the same issue: #18265

[Tommigun1980]

Microsoft, there seems to be quite a lot of developers who are confused about how to refresh the access token in a SignalR connection (me included), as the token factory seems to be executed only on connection start and if the token is revoked it's not checked for again. Could you please clarify what the suggested flow is for handling this as it is not brought up in the documentation. Thanks so much.

[davidfowl]

I think this is something we’ll have to think about more but let me ask some questions about the expected behavior:

Whats the ideal experience? Do you want to have the token expire and have the physical connection drop? That’s the easiest thing to do. The client would then re-connect and rerun then access token factory client side and you could re run whatever logic you need to to get a new token.

If we don’t do that does it mean the physical connection stays open and it’s less clear what it would do, how the client would re-negotiate etc

[mmulhearn]

IMO, the access token factory should maintain access token state and once the token expires, should invoke for a new one. If a new one is provided and is valid, the connection maintains, otherwise the connection drops.

[kherona]

@davidfowl I believe we should invoke new refresh token as suggested by mmulhearn, this is how we do it in non-websocket anyway, however the feature should be supported on client side/server side or both. Currently on server side we have read query_string and set Context.Token while I would expect the SignalR middle ware to automatically take care of that.

Now on the clientside I would suggest to add onAuthenticationFailure retry/reconnect (i.e 401 received) behavior similar to withAutomaticReconnect, then the accessTokenFactory can re-read whatever value we provided and attempt to reconnect the connection with the new accessTokenFactory.