I want to separate my login process from my game server, but I am trying to wrap my head around this...

This is my understanding / thoughts on how to implement the login server.

1. The client connects to the login server.

2. The client provides username and password

3. The server authenticates the username and password.

4. The server stores a unique code in database for the username.

5. The server sends the account id and unique code to the client.

6. The client tries to connect game using the account id and unique code.

7. The Game Server validates the unique code is within the allotted time between login and game server connection.

8. Client is now connected to the Game Server.

I may be completely off, since I have never done anything like this.

Thoughts? Ideas?

The end purpose of a login system is to authorize client's messages that he sends to the server and to associate a message with sender.

The prerequisite to do that is that your server is able to uniquely identify a client (an account) which you have discovered (account id).

Now, some do it differently but I strongly believe that account id (or some other unique identifier for an account) should not be publicly available to the client.

How I would do it probably would be:

1. client connects

2. client securely provides username and password

3. after validating login data, server generates a session id (some identifier) which will be used by client when sending messages. This id would be comprised for example of hash(account_id + salt) + validation data + random id + .... Session id is persisted.

4. From now on there is not really a "standard" way how to do it as it depends heavily on: server architecture, network topology of the server etc etc. To list a few options:

5.a) you have a proxy service (single point of entry) that is the only publicly exposed service of your game. Sole purpose of it is to validate session id it is sent to him with each message and forward the message to some internal service (usually, proxy services live on nodes that have at least 2 network interfaces, one public and one heavily firewalled internal one).So, each internal service can automatically trust the message from proxy service.

5.b) Maybe you have direct access from client to your server business logic code. In this scenario you would need to validate session on each message as well but on internal service layer

5.b) ...

TL;DR; You a figured out a good chuck of it but before you go for something like this, you NEED to be conceptually sound with the fact that what you are doing is trying to provide security and client association with messages, which pulls a lot of concepts with them.

Generally it similar as with all login related stuff: <generate_session_id> --> <validate_session_id_on_each_message>

You don't need to store a unique code in the database.

The typical login system looks like this:

client -> auth: (name, password)
auth -> client: ticket = (accountid, time, hmac(accountid + time, auth-secret))
client -> game: ticket

As long as the auth server and the game server both know the "auth-secret" and have clocks that are generally in sync (such as with NTP) then this will allow an auth server to authorize a particular account id at a particular time, without the game server having to check back in with the auth server.

The game server can use the time to figure out if it thinks this "ticket" is too old or not based on some setting that you decide.

For "hmac" you would typically want to use the HMAC function with the SHA256 hash function. (HMAC is an operation on top of a hash that protects against message extension attacks.)

Separately, to store the password in the database, you typically want to use scrypt of the plaintext password when the password is first set, and then verify the provided plain-text password on login using the scrypt verification function. And you'll want to use TLS for the login request (or, of you login over the web, use HTTPS or HTTP/2)