¿Cómo dividir el inicio de sesión y la lógica del juego al escribir servidores?

Estoy construyendo un servidor de juegos de póquer, iba a tener todos los inicios de sesión y la lógica del juego para ser manejados en un servidor, pero de mi investigación en la web, aprendí que esto no escalaría, y tendría sentido dividir el trabajo en un servidor de inicio de sesión y juegos. Pero lo que no obtengo es que después de manejar la autenticación en el servidor de inicio de sesión y hacer que el cliente establezca una nueva conexión con el servidor del juego, ¿cómo podría saber qué cliente es cuál? ¿No tendría que volver a iniciar sesión de nuevo y, por lo tanto, anular el propósito de tener un servidor para iniciar sesión? ¿Hay alguna forma de pasar una conexión a través de procesos y máquinas que no conozco? Disculpe mi poco conocimiento de las redes.

Aunque la respuesta de Philipp es perfectamente buena, hay una forma ligeramente diferente que no requiere una conexión entre el servidor de inicio de sesión y el servidor del juego, lo cual es útil si dicha conexión es difícil.

1. Cuando el usuario se autentica con éxito en el servidor de inicio de sesión, se le envía una dirección de servidor de juego y un token de inicio de sesión como se indicó anteriormente. Sin embargo, este token consta de 2 partes: el tiempo en el servidor de inicio de sesión y un hash de ese número más su nombre de usuario, su dirección IP, la dirección IP o ID del servidor del juego y una clave secreta que solo usted conoce.
2. El cliente intenta iniciar sesión en el servidor de juego proporcionado enviando este token. El servidor forma el mismo hash que antes, según la información en el token de inicio de sesión más su propia dirección IP / ID y la clave secreta. Si este hash coincide con el del token, sabes que el jugador se autenticó correctamente. Luego verifique que la fecha no sea demasiado antigua (p. Ej., Más de 1 minuto).

Esto funciona porque:

• No se puede copiar y reutilizar ya que la fecha caducará.
• No se puede construir sin un nuevo inicio de sesión sin conocer la clave secreta.
• No puede ser fácilmente interceptado por otra persona (por ejemplo, con un sniffer de paquetes) y utilizado porque la dirección IP original se utiliza para construirlo.
• No se puede usar para una cuenta diferente ya que el nombre de usuario forma parte del hash.
• No se puede usar para inicios de sesión simultáneos en diferentes servidores de juegos, ya que la dirección ID / IP del servidor forma parte del hash.

O, para decirlo de manera más simple, el hash asegura que es casi imposible que el remitente haya falsificado su token de inicio de sesión, por lo que se puede confiar en la información del token.

Al igual que con cualquier hash orientado a la seguridad, use la mejor función de hash que pueda obtener, en este momento a la gente parece gustarle bcrypt, PBKDF2 y scrypt, y asegúrese de que su clave secreta sea muy larga para que la reproducción de la fuerza bruta sea menos práctica.

1. Después de que el usuario se haya autenticado en el servidor de inicio de sesión, dele un token (una cadena única, generada aleatoriamente, demasiado larga para ser adivinada).

2. El servidor de inicio de sesión elige un servidor de juegos. Envíe el token, el nombre de usuario y todos los demás datos relevantes sobre el usuario desde el servidor de inicio de sesión al servidor que seleccionó.

3. Envíe el token y el nombre de host del servidor de juegos al cliente. Luego desconéctelo del servidor de inicio de sesión.

4. El cliente luego se conecta al servidor de juegos con su nombre de usuario y token.

5. Cuando el token del cliente coincide con el que acaba de informar el servidor de inicio de sesión, lo acepta.

Tenga en cuenta que para que esto sea seguro, los tokens deben crearse a partir de un generador de números aleatorios criptográficamente seguro, cada token solo puede ser aceptado una vez por el servidor de juegos y los tokens no utilizados deben descartarse después de unos minutos.