jiff
jiff copied to clipboard
multiparty
Authenticated Sockets
...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:
- Users enter his secret value.
- If correct, they receive a token, and that token is also stored in the database in the back-end.
- 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.
