Authentication between client, central server, and player ran server

Question

I am developing an open source game that uses a client-server scheme similar to Minecraft. We will control the central authentication server that verifies an account is valid, while players will run their own servers.

Authenticating the client is simple, but how can the server know that the user is valid, without having any access to is credentials or session token?

For example:

• Client > Auth Server: Sends user credentials.
• Auth Server > Client: Responds with a session ID if valid login.

Then, the client can connect to the server, but the server has no way of verifying is the client is who it says. These servers are ran by players, which make it easy for them to modify the server and collect the user data. (Only the central auth server can be trusted)

The authentication server could accept TCP connections, but I wonder if HTTPS would be easier in this case, as getting a response is easier than establishing a listener on each side, especially for only a few requests.

Answer 1

Edit: After posting this I realized it's almost the exact same answer given by Ali.S (slightly different but the overall approach is the same.) It started out as something completely different though.

This method assumes that all communications are being held over a series of secure tunnels. How you achieve this doesn't matter. I would suggest TLS, but that's just me.

1. Client => Game Server The client connects to the game server and initiates a login session.
2. Game Server => Auth Server The game server connects to the auth server and requests a session ID token from the auth server. This connection is kept open to listen for the login success/failure.
3. Game Server => Client The session ID token is sent back to the client.
4. Client => Auth Server The client sends the session ID to the auth server along with the username and password of the user, and some information about the server (IP, TLS public key, etc. See footnotes)
5. Auth Server => Game Server The auth server then sends information about the login to the game server (success state, username, stats, etc) using the session ID provided by the client.
6. Game Server => Client The game server tells the client that the auth was successful, and lets them in.
7. All connections except for the initial client to game server connection are now torn down.

Alternatively, you can give the game servers a dedicated port to listen for logins. If you choose this route, then the flow would look like this:

1. Client => Auth Server The client sends the username, password, and server IP to the auth server.
2. Auth Server => Game Server + Client If the login is successful, the auth server sends a unique token to the game server and client. Send the IP of the client to the game server too, so that the token can't be stolen.
3. Client => Game Server The client then sends the token to the game server, where it is then verified and deleted on the game server. The game server then lets the client in.

This second approach would make the overall implementation a bit easier.

Footnotes:

The reason I specify that some information should be sent about the game server to the auth server is to harden the process against spoofs. The server can verify the information to make sure that it is authorizing the connection that the player expects.

Session IDs would not have to be cryptographically secure, though it would make spoofing connections somewhat harder if they were.

If you do choose to go the TLS route, you can set up a signing server that signs all the certs used by your infrastructure, and add it as a trusted CA in the client/server software. So long as you don't let your signing cert get loose, you'll be able to provide some decent authentication.

For the sake of mitigating DoS attacks, make connections timeout after 20 or fewer seconds. If it lasts longer than that, then something is wrong and you don't need to wait 3 minutes waiting for the connection to timeout on its own.

Answer 2

The client should have a private and a public key.

The private key should be what the unique identifier that the client receives from the authentication server. The public key should be also sent to the client.

Before the client connects to a game server, it should send a message with its private key and the ip of the game server it wants to connect to, to the authentication server. The authentication server should then verify and find the match for the private key and store the public key in its records.

The game server that the client is connecting to should send a request to the authentication server after obtaining the public key of the client. If the authentication server can verify that the client wants to connect to that IP of the game server, send that it's an okay client back. The game server should then allow the client to connect.

The private key is only used for authentication of the client so that the game server doesn't obtain the real authentication id.

Answer 3

There are multiple solutions that I can think of, but here is the most secure one:

1. client connect to server.
2. client requests an authentication bridge.
3. server connects to auth server, acting as a proxy between player and auth. server.
4. client and auth server, form an SSL session over this newly formed bridge.
5. using this secure connection over bridge, client logins into auth server.
6. auth server tells game server whether the login was successful or not, over some other TCP connection. then disconnects it's bridge/login connection.
7. client and game server can now resume communication (only) over already existing connection (which was used for authentication).

Note that, in this scenario game server actually has no way of eavesdropping, even though the whole authentication is passing through it. for the same reason your ISP can't monitor what packets you send to Facebook, or are coming from facebook.

Answer 4

The way I would do this is by having Auth server send token to Client after login along with list of validated Game servers (so that the Client can be sure the Game server is valid).

Then the Client would send the token to the Game server, which would then send it to Auth server to confirm that this is the valid client.

Login:

1. Client to Auth server: username and encrypted password
2. Auth server to Client: token

Later when joining a Game server:

3. Client to Game server: the previously mentioned token
4. Game server to Auth server: again the token
5. Auth server to Game server: if token is valid then OK signal
6. Game server to Client: allows client to join

Answer 5

How about signing a JWT token with a secret only the central auth and player server knows? It lets you sign json, which can be verified later.