Editar: Después de publicar esto, me di cuenta de que es casi la misma respuesta dada por Ali.S (ligeramente diferente, pero el enfoque general es el mismo). Sin embargo, comenzó como algo completamente diferente.
Este método supone que todas las comunicaciones se mantienen en una serie de túneles seguros. Cómo lograr esto no importa. Sugeriría TLS, pero solo soy yo.
- Cliente => Servidor del juego El cliente se conecta al servidor del juego e inicia una sesión de inicio de sesión.
- Servidor de juegos => Servidor de autenticación El servidor de juegos se conecta al servidor de autenticación y solicita un token de ID de sesión del servidor de autenticación. Esta conexión se mantiene abierta para escuchar el inicio / error de inicio de sesión.
- Game Server => Cliente El token de ID de sesión se envía de vuelta al cliente.
- Cliente => Servidor de autenticación El cliente envía la ID de sesión al servidor de autenticación junto con el nombre de usuario y la contraseña del usuario, y cierta información sobre el servidor (IP, clave pública TLS, etc. Ver notas al pie)
- Servidor de autenticación => Servidor de juegos El servidor de autenticación envía información sobre el inicio de sesión al servidor de juegos (estado de éxito, nombre de usuario, estadísticas, etc.) utilizando el ID de sesión proporcionado por el cliente.
- Servidor de juegos => Cliente El servidor de juegos le dice al cliente que la autenticación fue exitosa y los deja entrar.
- Todas las conexiones, excepto la conexión inicial del cliente al servidor del juego, ahora se eliminan.
Alternativamente, puede dar a los servidores del juego un puerto dedicado para escuchar los inicios de sesión. Si elige esta ruta, el flujo se vería así:
- Cliente => Servidor de autenticación El cliente envía el nombre de usuario, la contraseña y la IP del servidor al servidor de autenticación.
- Auth Server => Game Server + Client Si el inicio de sesión es exitoso, el servidor de autenticación envía un token único al servidor y al cliente del juego. Envíe también la IP del cliente al servidor del juego, para que no se pueda robar el token.
- Cliente => Servidor del juego El cliente envía el token al servidor del juego, donde luego se verifica y elimina en el servidor del juego. El servidor del juego luego deja entrar al cliente.
Este segundo enfoque facilitaría un poco la implementación general.
Notas al pie:
La razón por la que especifico que se debe enviar cierta información sobre el servidor del juego al servidor de autenticación es para endurecer el proceso contra las falsificaciones. El servidor puede verificar la información para asegurarse de que está autorizando la conexión que el jugador espera.
Las ID de sesión no tendrían que ser criptográficamente seguras, aunque haría que las conexiones de suplantación fueran algo más difíciles si lo fueran.
Si elige ir a la ruta TLS, puede configurar un servidor de firma que firme todos los certificados utilizados por su infraestructura y agregarlo como una CA confiable en el software cliente / servidor. Mientras no permita que su certificado de firma se pierda, podrá proporcionar una autenticación decente.
En aras de mitigar los ataques DoS, agota el tiempo de espera de las conexiones después de 20 segundos o menos. Si dura más que eso, entonces algo está mal y no necesita esperar 3 minutos esperando que la conexión se agote por sí sola.
El cliente debe tener una clave privada y una pública .
La clave privada debe ser el identificador único que el cliente recibe del servidor de autenticación. La clave pública también debe enviarse al cliente.
Antes de que el cliente se conecte a un servidor de juegos, debe enviar un mensaje con su clave privada y la ip del servidor de juegos al que desea conectarse, al servidor de autenticación. El servidor de autenticación debería verificar y encontrar la coincidencia para la clave privada y almacenar la clave pública en sus registros.
El servidor de juegos al que se conecta el cliente debe enviar una solicitud al servidor de autenticación después de obtener la clave pública del cliente. Si el servidor de autenticación puede verificar que el cliente desea conectarse a esa IP del servidor del juego, envíe que es un cliente correcto. El servidor del juego debería permitir que el cliente se conecte.
La clave privada solo se usa para la autenticación del cliente para que el servidor del juego no obtenga la identificación de autenticación real.
fuente
Hay varias soluciones en las que puedo pensar, pero esta es la más segura:
Tenga en cuenta que, en este escenario, el servidor de juego en realidad no tiene forma de espiar, a pesar de que toda la autenticación está pasando por él. por la misma razón, su ISP no puede monitorear qué paquetes envía a Facebook o si provienen de Facebook.
fuente
La forma en que haría esto es haciendo que el servidor Auth envíe un token al Cliente después de iniciar sesión junto con una lista de servidores de Juego validados (para que el Cliente pueda estar seguro de que el servidor del Juego es válido).
Luego, el Cliente enviaría el token al servidor del Juego, que luego lo enviaría al servidor Auth para confirmar que este es el cliente válido.
Iniciar sesión:
Más tarde, cuando te unas a un servidor de juegos:
fuente
¿Qué tal firmar un token JWT con un secreto que solo el servidor central de autenticación y el jugador conoce? Le permite firmar json, que se puede verificar más adelante.
fuente