Autenticación entre el cliente, el servidor central y el servidor ejecutado por el jugador

Estoy desarrollando un juego de código abierto que utiliza un esquema cliente-servidor similar a Minecraft. Controlaremos el servidor de autenticación central que verifica que una cuenta sea válida, mientras que los jugadores ejecutarán sus propios servidores.

Autenticar al cliente es simple, pero ¿cómo puede saber el servidor que el usuario es válido, sin tener acceso a sus credenciales o token de sesión?

Por ejemplo:

• Cliente> Servidor de autenticación: envía credenciales de usuario.
• Servidor de autenticación> Cliente: responde con un ID de sesión si es un inicio de sesión válido.

Luego, el cliente puede conectarse al servidor, pero el servidor no tiene forma de verificar si el cliente es quien dice. Los jugadores ejecutan estos servidores, lo que les facilita modificar el servidor y recopilar los datos del usuario. (Solo se puede confiar en el servidor de autenticación central)

El servidor de autenticación podría aceptar conexiones TCP, pero me pregunto si HTTPS sería más fácil en este caso, ya que obtener una respuesta es más fácil que establecer un escucha en cada lado, especialmente para unas pocas solicitudes.

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.

1. Cliente => Servidor del juego El cliente se conecta al servidor del juego e inicia una sesión de inicio de sesión.
2. 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.
3. Game Server => Cliente El token de ID de sesión se envía de vuelta al cliente.
4. 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)
5. 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.
6. Servidor de juegos => Cliente El servidor de juegos le dice al cliente que la autenticación fue exitosa y los deja entrar.
7. 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í:

1. 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.
2. 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.
3. 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.

Hay varias soluciones en las que puedo pensar, pero esta es la más segura:

1. El cliente se conecta al servidor.
2. El cliente solicita un puente de autenticación.
3. El servidor se conecta al servidor de autenticación, actuando como un proxy entre el jugador y la autenticación. servidor.
4. cliente y servidor de autenticación, forman una sesión SSL sobre este puente recién formado.
5. Al utilizar esta conexión segura a través del puente, el cliente inicia sesión en el servidor de autenticación.
6. auth server le dice al servidor del juego si el inicio de sesión fue exitoso o no, a través de alguna otra conexión TCP. luego desconecta su conexión de puente / inicio de sesión.
7. El cliente y el servidor del juego ahora pueden reanudar la comunicación (solo) a través de una conexión ya existente (que se utilizó para la autenticación).

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.

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:

1. Cliente a servidor de autenticación: nombre de usuario y contraseña cifrada
2. Servidor de autenticación al cliente: token

Más tarde, cuando te unas a un servidor de juegos:

3. Cliente a servidor del juego: el token mencionado anteriormente
4. Servidor de juego a servidor de autenticación: nuevamente el token
5. Auth server to Game server: si el token es válido, entonces señal OK
6. Servidor del juego al cliente: permite que el cliente se una

¿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.