CODEWITHSUNDEEP
asp.net-coresignalrasp.net-core-signalr
logix
logix

Reputation: 642

ASP.Net Core SignalR bearer token on negotiate

From reading the Microsoft docs on authentication with SignalR, it looks like the only way to authenticate using a bearer token is to send it in the query string on the WebSocket connection.

Upon inspecting the SignalR handshake, it looks like the Authorization header is included in the Negotiate call. Since the connection ID is returned in the negotiate response, the server could keep track of whether that connection ID has authenticated.

Why is it required to add the bearer token to the Websocket connection query string as well?

Upvotes: 4

Views: 5108

Answers (1)

OO7
OO7

Reputation: 690

It seems this is the clue for your question.

When using WebSockets or Server-Sent Events, the browser client sends the access token in the query string. Receiving the access token via query string is generally secure as using the standard Authorization header. Always use HTTPS to ensure a secure end-to-end connection between the client and the server.

Security considerations in ASP.NET Core SignalR

This is the alternative:

SignalR can be used with ASP.NET Core authentication to associate a user with each connection. In a hub, authentication data can be accessed from the HubConnectionContext.User property. Authentication allows the hub to call methods on all connections associated with a user. For more information, see Manage users and groups in SignalR. Multiple connections may be associated with a single user.

Authenticate users connecting to a SignalR hub

Additional: However, I think you can also try some injection for both server and client. On server eg. use websocket helper and on client eg. use Promise vs XMLHttpRequest.

Upvotes: 1

Related Questions