WSS Authentication

squirrel · 2025-08-18 08:52:43

Is there currently a way to ensure that https can only be upgraded to wss connections for already authenticated/logged in users and then to be able to link the wss requests/connectionids to the specific logged in user?

flydev · 2025-08-18 09:15:18

If it helps you find the way, on my side, I use TWebSocketProtocol.UpgradeBearerToken for that: read more there

squirrel · 2025-08-18 09:33:54

My initial thought was to define a protocol that is similar to the http uri signing, which would keep things standard for third parties. Then wss commands can be sent using a signing format similar to this:

{
    "command": "/root/mycommand?session_signature=same as calculated as if command was a uri",
    "parameters": {}
}

But then I would need to somehow pass the command to the rest server for the authentication to be checked. The advantage would be that, if a user logs out from the https server, the wss functions will also fail. So no additional session management would have to be done.

ab · 2025-08-18 12:45:41

You can set the OnBeforeBody event handler to check the URI and reject it.

But I may add something more integrated with the TRestServer instance.

flydev · 2025-08-18 12:49:02

to check the command you show you could do it in InBeforeBody, you could validate specific upgrade in flags hsrConnectionUpgrade.

edit: what @ab just said

Last edited by flydev (2025-08-18 12:49:38)

squirrel · 2025-08-18 12:52:52

Thanks @ab. How would I send the uri to TRestServerAuthenticationDefault for verification? Is there a function I am missing that takes a uri and returns a session? I have searched, but may have missed it.

Does TWebSocketAsyncServer have an OnBeforeBody property?

ab · 2025-08-18 13:15:04

This is indeed the problem.

There are several issues:

1) The TRestHttpServer can handle several TRestServer instances, with a complex redirection system which may involve THttpServerRequestAbstract.Host value.
So it is not easy to redirect to the proper TRestServer. We could restrict to a single server.

2) The URI authentication is using a TRestServerUriContext instance, which does not exist yet when the WebSockets upgrade is done.

3) The URI authentication depends on the actual URI used.

So I guess it would need to add a dedicated method to TRestServerAuthentication...
Which seems pretty much complex for such a task.

ab · 2025-08-18 13:26:46

Note that you have an alternative to OnBeforeBody.

You can just set an aOnWSUpgraded: TOnWebSocketProtocolUpgraded callback as parameter to WebSocketsEnable().
Then, don't use the mORMot URI signing, but a custom challenge, either in the URI or in the bearer.
Note that putting a signature in an URI should always be time-limited to avoid replay attacks.

ab · 2025-08-18 17:24:24

Please try with
https://github.com/synopse/mORMot2/commit/1e3a67727

There is now a new rsoWebSocketsUpgradeSigned option which will require either a HTTP bearer or a specific URI parameter when upgrading to websockets.
You just supply the URI or the bearer from a safe service method, then use this value to upgrade.

On the client side:
https://github.com/synopse/mORMot2/commit/f322cc420

My guess is that this pattern (which I have commonly used before) is the right to use for safe WebSockets upgrade, in a cross-platform way.

squirrel · Yesterday 08:58:55

Wow that was quick, thanks @ab!

I'm trying to understand the workflow of the new solution, but not very sure how to implement it. It looks as if the upgrade to websockets replaces the mormot signing/authentication with cookies?

ab · Yesterday 09:58:04

It is only for the Websockets upgrade itself.
Other regular HTTP requests are not affected.

But if you restrict your system to only support WebSockets connections on the server, it may be a good way to secure your service.
If it is properly used, and all other methods and services are setup to require a websockets, then TRestServerAuthenticationNone could be enough.
It is exactly the same as with a JWT bearer: in OnBeforeBody, you could only allow the upgrade URI (and perhaps /root/timestamp) and you would have a secure endpoint.

mORMot Open Source

#1 2025-08-18 08:52:43

WSS Authentication

#2 2025-08-18 09:15:18

Re: WSS Authentication

#3 2025-08-18 09:33:54

Re: WSS Authentication

#4 2025-08-18 12:45:41

Re: WSS Authentication

#5 2025-08-18 12:49:02

Re: WSS Authentication

#6 2025-08-18 12:52:52

Re: WSS Authentication

#7 2025-08-18 13:15:04

Re: WSS Authentication

#8 2025-08-18 13:26:46

Re: WSS Authentication

#9 2025-08-18 17:24:24

Re: WSS Authentication

#10 Yesterday 08:58:55

Re: WSS Authentication

#11 Yesterday 09:58:04

Re: WSS Authentication

Board footer