Websockets and sessions

squirrel · 2024-07-31 08:51:26

I need bidirectional communication between my current rest server and webclients. Websockets seem to be the obvious solution for this, but i am not sure how to handle the authentication side of things. Currently the standard mormot auth is used for the rest calls and that works very well. But when upgrading the connection to ws there wont really be a url to sign when sending messages. Switching to JWT seems like a bad idea, because then we'd be open to replay attacks.

Has anybody implemented an authentication/session scheme over websockets? I would really appreciate some tips and guidance from someone who has gone through this.

ab · 2024-07-31 08:57:47

The easiest is to use a JWT for this, as authentication bearer, during the WebSockets upgrade.
Then, you don't need any more authentication in the websockets packets themselves, because they are still authenticated by the initial WebSockets upgrade.
If the connection is broken/lost, the client need to upgrade again, with a proper JWT as authentication bearer.

Of course, if you don't like JWT, you could still use other means of authentication as proposed by our THttpServerGeneric classes - e.g. Digest, or you own challenge.
The same idea apply: the WebSockets communication is authenticated once during its upgrade.

Anyway, using TLS is mandatory on production - at least with a self-signed certificate - to obfuscate the transmitted data.
JWT over TLS is safe: you can't see the token, so you can't replay it.
Note that the mORMOt auth is subject to replay, if you don't use TLS.
And the safest approach is to use client authentication using a client certificate, if your business logic supports it.

Also note that I will finalize official Socket.IO support in mORMot 2 in the next days.
It may be a good way to use notifications, also from other clients, e.g. in JavaScript or Python.

squirrel · 2024-07-31 11:00:46

Thanks @ab. Then it may be a good idea for me to wait a few days.

squirrel · 2024-08-01 11:11:32

There are now so many server types, that its becoming a bit difficult to determine when and how to use the different server types. Is the TWebSocketAsyncServerRest supposed to be used together with a TRestServer similar to how its used with TRestHttpServer, or how should the different interface functions be triggered?

ab · 2024-08-01 14:11:56

No need to play with the classes.

Just use a TRestHttpServer and define WEBSOCKETS_DEFAULT_MODE (or useBidirAsync or useBidirSocket).

The define the callbacks as interface parameters in your SOA definition.
That is all you need.

squirrel · 2024-08-02 06:35:23

Ok, this makes a lot of sense, and it looks like this is what is done in the restws_chatserver sample project

Just use a TRestHttpServer and define WEBSOCKETS_DEFAULT_MODE (or useBidirAsync or useBidirSocket)

But this is where I start to feel like a preschool child learning the alphabet:

The define the callbacks as interface parameters in your SOA definition

From the sample project, it looks as if the interfaces has to be defined twice. One that does the work and always contain a callback parameter in all the functions, and one that is used to send the response to the request. When a response needs to be sent, the working function needs to step through all the connections manually, find the appropriate one and trigger the callback, then delete it from the list of callbacks? Since there is no implementation of the callback interface's functions, I guess only one standard one needs to be defined?

Thanks, not sure yet how to fit that workflow in with a javascript client, but will try.

ab · 2024-08-02 07:22:28

For how interface parameters and websockets work, the mORMot 1 documentation still applies.
https://synopse.info/files/html/Synopse … l#TITL_149

But our own protocol is not directly usable with a JavaScript client, because there are some plumbing and conventions used for the encoding.
For a JavaScript client, a plain TWebSocketProtocolChat is enough - but Sockets.io is coming soon.

mORMot Open Source

#1 2024-07-31 08:51:26

Websockets and sessions

#2 2024-07-31 08:57:47

Re: Websockets and sessions

#3 2024-07-31 11:00:46

Re: Websockets and sessions

#4 2024-08-01 11:11:32

Re: Websockets and sessions

#5 2024-08-01 14:11:56

Re: Websockets and sessions

#6 2024-08-02 06:35:23

Re: Websockets and sessions

#7 2024-08-02 07:22:28

Re: Websockets and sessions

Board footer