Master server design

[Ali_RS]

Just to be sure I am still in the right path!

@jayfella now that I have a separate server for the account and each app, does it make sense to switch my JWT auth algorithm from HS512 hash-based authentication to the RS256 signature?

So each app can authenticate requests independently by using the shared public key.

[jayfella]

If you mean RS256 - yes. A public/private key will just make things a lot more secure since you can’t control the client.

[Ali_RS]

Yes RS256

And thank you for the quick response.

[Ali_RS]

@jayfella

• User creates an account. They are now allowed to use your game, either as a player or server owner.
• User decides to set up a gameserver.
• User requests to register a new gameserver.
• Server responds by giving the user an oauth token (per gameserver. A user can have 10 servers if they want and each server will have a unique oauth token). You can restrict the amount they can have if you want.
• This token has permission to CRUD a single gameserver data and nothing else.
• User puts that oauth token in their gameserver settings.
• Users new gameserver starts. It sends data to the server with oauth token.
• Server checks if the oauth token is valid.
• Server responds OK with the CRUD request if the oauth token is valid.

So far so clear

What about when some client wants to connect to the game server.

Suppose client has already got the ip:port of the game server from the master server and now wants to make a connection to game server.

Should I also give the client a temporary access token to use when connecting a game server? So the game server can also safely authenticate who is being connected, either doing itself by using the shared public-key or by asking from the master server.

[jayfella]

Yes. Of sorts.

The user requests to join with their session ID they got when they logged in.

GameServer checks SID with auth server and accepts/rejects.

If accepted, auth server sets “active game” column to server token.

Their Session ID can only be part of one game. To do that you bind an “active game” column to a user. This stops single users logging into multiple games (account sharing).

Now you know who is connected to what. But you don’t want to keep querying the main server after they have joined successfully. From here-on you can accept the connection as valid.

Send the user back a token from the game-server. Do NOT use the original SID because that’s a password for all intent with ALL permissions. Use that token as a user reference to communicate bi-directionally.

[Ali_RS]

@jayfella

The user requests to join with their session ID they got when they logged in.

Actually, in my case, all my REST endpoints are stateless (not session based), and every time the user login he gets a newly created JWT token valid for 48H, and from now on he uses this token to make a call to my REST endpoints.

If I got you right this Session ID is something that varies on each login, Yes? for example a random UUID.

And If I understand it correctly the Session ID should be a column in user account table that gets updated every time user login. And the client should use this Session ID to connect to the game server.