Autenticação entre cliente, servidor central e player executou o servidor

Estou desenvolvendo um jogo de código aberto que usa um esquema cliente-servidor semelhante ao Minecraft. Controlaremos o servidor de autenticação central que verifica se uma conta é válida, enquanto os jogadores executam seus próprios servidores.

A autenticação do cliente é simples, mas como o servidor pode saber que o usuário é válido, sem ter acesso a credenciais ou token de sessão?

Por exemplo:

• Cliente> Servidor de autenticação: envia credenciais do usuário.
• Servidor de autenticação> Cliente: responde com um ID de sessão se o login for válido.

Em seguida, o cliente pode se conectar ao servidor, mas o servidor não tem como verificar se o cliente é quem diz. Esses servidores são executados por jogadores, o que facilita a modificação do servidor e a coleta de dados do usuário. (Somente o servidor de autenticação central pode ser confiável)

O servidor de autenticação pode aceitar conexões TCP, mas me pergunto se o HTTPS seria mais fácil nesse caso, pois obter uma resposta é mais fácil do que estabelecer um ouvinte de cada lado, especialmente para apenas algumas solicitações.

Edit: Depois de postar isso, eu percebi que é quase a mesma resposta dada por Ali.S (ligeiramente diferente, mas a abordagem geral é a mesma.) Começou como algo completamente diferente.

Este método pressupõe que todas as comunicações estão sendo mantidas em uma série de túneis seguros. Como você consegue isso não importa. Eu sugeriria TLS, mas sou apenas eu.

1. Cliente => Servidor do Jogo O cliente se conecta ao servidor do jogo e inicia uma sessão de login.
2. Servidor de jogos => Servidor de autenticação O servidor de jogos se conecta ao servidor de autenticação e solicita um token de ID de sessão ao servidor de autenticação. Essa conexão é mantida aberta para escutar o êxito / falha do logon.
3. Servidor de Jogo => Cliente O token da ID da sessão é enviado de volta ao cliente.
4. Cliente => Servidor de autenticação O cliente envia a ID da sessão ao servidor de autenticação, juntamente com o nome de usuário e a senha do usuário, além de algumas informações sobre o servidor (IP, chave pública TLS, etc. Veja notas de rodapé)
5. Servidor de autenticação => Servidor de jogos O servidor de autenticação envia informações sobre o logon para o servidor de jogos (estado de sucesso, nome de usuário, estatísticas, etc.) usando a ID da sessão fornecida pelo cliente.
6. Servidor de jogos => Cliente O servidor de jogos informa ao cliente que a autenticação foi bem-sucedida e os deixa entrar.
7. Todas as conexões, exceto a conexão inicial do cliente com o servidor do jogo, agora estão desativadas.

Como alternativa, você pode dar aos servidores de jogos uma porta dedicada para ouvir logins. Se você escolher essa rota, o fluxo ficaria assim:

1. Cliente => Servidor de autenticação O cliente envia o nome de usuário, a senha e o IP do servidor para o servidor de autenticação.
2. Servidor de autenticação => Servidor de jogo + Cliente Se o login for bem-sucedido, o servidor de autenticação envia um token exclusivo para o servidor e o cliente de jogo. Envie o IP do cliente também para o servidor do jogo, para que o token não possa ser roubado.
3. Cliente => Servidor do Jogo O cliente envia o token para o servidor do jogo, onde é verificado e excluído no servidor do jogo. O servidor do jogo deixa o cliente entrar.

Essa segunda abordagem tornaria a implementação geral um pouco mais fácil.

Notas de rodapé:

A razão pela qual especifico que algumas informações devem ser enviadas sobre o servidor do jogo para o servidor de autenticação é para fortalecer o processo contra spoofs. O servidor pode verificar as informações para garantir que está autorizando a conexão que o player espera.

Os IDs de sessão não precisariam ser criptograficamente seguros, embora isso tornasse as conexões falsas um pouco mais difíceis se fossem.

Se você optar por seguir a rota TLS, poderá configurar um servidor de assinatura que assine todos os certificados usados ​​por sua infraestrutura e adicioná-lo como uma CA confiável no software cliente / servidor. Contanto que você não solte seu certificado de assinatura, você poderá fornecer uma autenticação decente.

Para minimizar os ataques de DoS, faça o tempo limite das conexões após 20 segundos ou menos. Se durar mais do que isso, algo está errado e você não precisa esperar 3 minutos aguardando o tempo limite da conexão por conta própria.

O cliente deve ter uma chave privada e uma pública .

A chave privada deve ser o identificador exclusivo que o cliente recebe do servidor de autenticação. A chave pública também deve ser enviada ao cliente.

Antes que o cliente se conecte a um servidor de jogos, ele deve enviar uma mensagem com sua chave privada e o IP do servidor de jogos ao qual deseja se conectar, ao servidor de autenticação. O servidor de autenticação deve verificar e encontrar a correspondência para a chave privada e armazenar a chave pública em seus registros.

O servidor do jogo ao qual o cliente está se conectando deve enviar uma solicitação ao servidor de autenticação após obter a chave pública do cliente. Se o servidor de autenticação puder verificar se o cliente deseja se conectar ao IP do servidor do jogo, envie-o de volta para o cliente correto. O servidor do jogo deve permitir que o cliente se conecte.

A chave privada é usada apenas para autenticação do cliente, para que o servidor do jogo não obtenha o ID de autenticação real.

Existem várias soluções em que posso pensar, mas aqui está a mais segura:

1. cliente se conectar ao servidor.
2. cliente solicita uma ponte de autenticação.
3. servidor se conecta ao servidor de autenticação, atuando como um proxy entre o player e o auth. servidor.
4. cliente e servidor de autenticação, forme uma sessão SSL sobre essa ponte recém-formada.
5. usando essa conexão segura pela ponte, o cliente efetua login no servidor de autenticação.
6. O servidor de autenticação informa ao servidor do jogo se o logon foi bem-sucedido ou não, em alguma outra conexão TCP. então desconecta sua conexão de ponte / login.
7. Agora, o cliente e o servidor do jogo podem retomar a comunicação (apenas) pela conexão já existente (usada para autenticação).

Observe que, nesse cenário, o servidor do jogo não tem como escutar, mesmo que toda a autenticação esteja passando por ele. pelo mesmo motivo, seu ISP não pode monitorar quais pacotes você envia para o Facebook ou são provenientes do facebook.

A maneira como eu faria isso é fazendo com que o servidor Auth envie o token para o Cliente após o login, juntamente com a lista de servidores de jogos validados (para que o cliente possa ter certeza de que o servidor do jogo é válido).

Em seguida, o cliente enviaria o token para o servidor do jogo, que o enviaria ao servidor de autenticação para confirmar que este é o cliente válido.

Conecte-se:

1. Cliente para servidor de autenticação: nome de usuário e senha criptografada
2. Servidor de autenticação para o cliente: token

Mais tarde, ao ingressar em um servidor de jogos:

3. Cliente para servidor do jogo: o token mencionado anteriormente
4. Servidor de jogo para servidor de autenticação: novamente o token
5. Servidor de autenticação para servidor de jogos: se o token for válido, sinal OK
6. Servidor de jogo para o cliente: permite que o cliente ingresse

Que tal assinar um token JWT com um segredo que apenas o servidor central de autenticação e player conhece? Permite assinar o json, que pode ser verificado posteriormente.