Como dividir a lógica de logon e jogo ao escrever servidores?

Eu estou construindo um servidor de pôquer como o jogo, eu teria todos os logins e lógica de jogo para serem manipulados em um servidor, mas, com minha pesquisa na web, eu aprendi que isso não seria escalável e faria sentido dividir o trabalho em servidores de logon e jogo. Mas o que eu não entendo é que depois que lidei com a autenticação no servidor de logon e o cliente fez uma nova conexão com o servidor do jogo, como eu saberia qual cliente é qual? Não precisaria fazer o login novamente novamente e, assim, anular o propósito de ter um servidor para login? Existe alguma maneira de transmitir uma conexão entre processos e máquinas que eu não conheço? Desculpe meu pouco conhecimento de rede.

Embora a resposta de Philipp seja perfeitamente boa, existe uma maneira um pouco diferente que não requer uma conexão entre o servidor de login e o servidor do jogo, o que é útil se a conexão for difícil.

1. Quando o usuário se autentica com sucesso no servidor de logon, ele recebe um endereço do servidor de jogo e um token de logon, como acima. No entanto, esse token consiste em 2 partes: a hora no servidor de login e um hash desse número, mais o nome de usuário, o endereço IP, o endereço IP ou o ID do servidor do jogo e uma chave secreta que somente você conhece.
2. O cliente tenta fazer login no servidor de jogos fornecido enviando esse token. O servidor forma o mesmo hash de antes, com base nas informações no token de login, mais seu próprio endereço IP / ID e a chave secreta. Se esse hash corresponder ao do token, você saberá que o jogador foi autenticado corretamente. Depois verifique se a data não é muito antiga (por exemplo, mais de 1 minuto).

Isso funciona porque:

• Não pode ser copiado e reutilizado, pois a data expira.
• Não pode ser construído sem um novo login sem conhecer a chave secreta.
• Ele não pode ser facilmente interceptado por outra pessoa (por exemplo, com um sniffer de pacote) e usado porque o endereço IP original é usado para construí-lo.
• Ele não pode ser usado para uma conta diferente, pois o nome de usuário faz parte do hash.
• Ele não pode ser usado para logins simultâneos em diferentes servidores de jogos, pois o endereço IP / ID do servidor faz parte do hash.

Ou, para simplificar, o hash garante que é quase impossível para o remetente falsificar seu token de login e, portanto, confiar nas informações no token.

Como em qualquer hash orientado a segurança, use a melhor função de hash que você pode obter - no momento, as pessoas parecem gostar de bcrypt, PBKDF2 e scrypt - e garanta que sua chave secreta seja muito longa para tornar a reprodução de força bruta menos prática.

1. Depois que o usuário se autenticar no servidor de logins, forneça um token (uma sequência exclusiva gerada aleatoriamente por muito tempo para ser adivinhada).

2. O servidor de log escolhe um servidor de jogos. Envie o token, o nome de usuário e todos os outros dados relevantes sobre o usuário do servidor de logon para o servidor escolhido.

3. Envie o token e o nome do host do servidor de jogos para o cliente. Em seguida, desconecte-o do servidor de logins.

4. O cliente então se conecta ao servidor de jogos com seu nome de usuário e token.

5. Quando o token do cliente corresponde ao que foi relatado pelo servidor de logins, você o aceita.

Observe que, para que isso seja seguro, os tokens precisam ser criados a partir de um gerador de números aleatórios criptograficamente seguro; cada token pode ser aceito apenas uma vez pelo servidor de jogos e os tokens não utilizados devem ser descartados após alguns minutos.