Authenticated Sockets

[KinanBab]

Look into using authenticated sockets to prevent imposters.

[KinanBab]

https://auth0.com/blog/auth-with-socket-io/

[842Mono]

...first of all, socket.io allows parameters to be sent along with the url that's used to establish the connection (example: https://localhost:8080/users?token=abc). We can use that to verify the authenticity of sockets right when they connect, and easily reject any sockets that fail to authenticate.

How are we going to determine whether a user is legit or an imposter? He has to identify himself. We probably need a username-password system? If we want to have minimal interaction with the users, and a "username" doesn't make much sense we can use some "identifier only" system; like a "password only" system, or we can extract a hardware ID from the machine (not a very good idea, they can be faked), or supply the ID in a config file. But all those ideas boil down to the same concept. The user has to supply a secret value to authenticate.

When a user supplies a value we can generate a token. we can use JWTs. This token can be ultimately used to identify a user, and can even be used to reject multiple socket connections from the same user. It also can be used to allow users to join specific computations only.

A good idea is to offload the responsibility of authenticating users to an independent server or entity (let's call it A). (Independent in the sense of code). It can use a simple express server with a mongo database. The users provide their value to A and A generates a token, sends it back to the user and also stores it in the database. Later, the server-side jiff can just look up that database to verify any provided tokens. A can run on the same server on another port or on a different port.

So this should be the authentication story:

1. Users enter his secret value.
2. If correct, they receive a token, and that token is also stored in the database in the back-end.
3. The user does "make_jiff" and he automatically presents his token to the server.
   4 & 5) The server checks the database for the token and either accepts or rejects the connection.