Autenticazione tra client, server centrale e player con server eseguito

Sto sviluppando un gioco open source che utilizza uno schema client-server simile a Minecraft. Controlleremo il server di autenticazione centrale che verifica che un account sia valido, mentre i giocatori eseguiranno i propri server.

L'autenticazione del client è semplice, ma come fa il server a sapere che l'utente è valido, senza avere accesso a credenziali o token di sessione?

Per esempio:

• Client> Server di autenticazione: invia le credenziali dell'utente.
• Server di autenticazione> Client: risponde con un ID di sessione se l'accesso è valido.

Quindi, il client può connettersi al server, ma il server non ha modo di verificare se il client è chi dice. Questi server sono gestiti dai giocatori, il che semplifica la modifica del server e la raccolta dei dati dell'utente. (Solo il server di autenticazione centrale può essere considerato attendibile)

Il server di autenticazione potrebbe accettare connessioni TCP, ma mi chiedo se HTTPS sarebbe più semplice in questo caso, poiché ottenere una risposta è più semplice che stabilire un listener su ciascun lato, specialmente solo per alcune richieste.

Modifica: dopo aver pubblicato questo mi sono reso conto che è quasi la stessa identica risposta data da Ali.S (leggermente diverso ma l'approccio generale è lo stesso.) È iniziato come qualcosa di completamente diverso.

Questo metodo presuppone che tutte le comunicazioni siano mantenute su una serie di tunnel sicuri. Non importa come raggiungi questo obiettivo. Suggerirei TLS, ma sono solo io.

1. Client => Server di gioco Il client si connette al server di gioco e avvia una sessione di accesso.
2. Server di gioco => Server di autenticazione Il server di gioco si collega al server di autenticazione e richiede un token ID di sessione dal server di autenticazione. Questa connessione è mantenuta aperta per ascoltare l'esito positivo / negativo dell'accesso.
3. Game Server => Client Il token ID sessione viene inviato al client.
4. Client => Server di autenticazione Il client invia l'ID di sessione al server di autenticazione insieme al nome utente e alla password dell'utente e ad alcune informazioni sul server (IP, chiave pubblica TLS, ecc. Vedi le note a piè di pagina)
5. Server di autenticazione => Server di gioco Il server di autenticazione invia quindi informazioni sull'accesso al server di gioco (stato di successo, nome utente, statistiche, ecc.) Utilizzando l'ID sessione fornito dal client.
6. Game Server => Client Il server di gioco comunica al client che l'autent ha avuto successo e li fa entrare.
7. Tutte le connessioni ad eccezione della connessione iniziale tra client e server di gioco sono state demolite.

In alternativa, puoi assegnare ai server di gioco una porta dedicata per ascoltare gli accessi. Se scegli questa rotta, il flusso sarebbe simile al seguente:

1. Client => Server di autenticazione Il client invia il nome utente, la password e l'IP del server al server di autenticazione.
2. Server di autenticazione => Server di gioco + client Se l'accesso ha esito positivo, il server di autenticazione invia un token univoco al server di gioco e al client. Invia anche l'IP del client al server di gioco, in modo che il token non possa essere rubato.
3. Client => Server di gioco Il client invia quindi il token al server di gioco, dove viene quindi verificato ed eliminato sul server di gioco. Il server di gioco consente quindi al client di entrare.

Questo secondo approccio renderebbe un po 'più semplice l'implementazione complessiva.

Note:

Il motivo per cui specifico che alcune informazioni dovrebbero essere inviate sul server di gioco al server di autenticazione è di rafforzare il processo contro gli spoofing. Il server può verificare le informazioni per assicurarsi che stia autorizzando la connessione prevista dal lettore.

Gli ID di sessione non dovrebbero essere crittograficamente sicuri, anche se renderebbero le connessioni di spoofing un po 'più difficili se lo fossero.

Se si sceglie di seguire il percorso TLS, è possibile configurare un server di firma che firma tutte le certificazioni utilizzate dalla propria infrastruttura e aggiungerlo come CA attendibile nel software client / server. Finché non lasci che il certificato di firma si allenti, sarai in grado di fornire un'autenticazione decente.

Per mitigare gli attacchi DoS, effettuare il timeout delle connessioni dopo 20 o meno secondi. Se dura più a lungo, qualcosa non va e non è necessario attendere 3 minuti in attesa del timeout della connessione da solo.

Il client dovrebbe avere una chiave privata e una pubblica .

La chiave privata dovrebbe essere l'identificatore univoco che il client riceve dal server di autenticazione. La chiave pubblica deve essere inviata anche al client.

Prima che il client si connetta a un server di gioco, deve inviare un messaggio con la sua chiave privata e l'ip del server di gioco a cui desidera connettersi al server di autenticazione. Il server di autenticazione dovrebbe quindi verificare e trovare la corrispondenza per la chiave privata e archiviare la chiave pubblica nei suoi record.

Il server di gioco a cui si sta connettendo il client dovrebbe inviare una richiesta al server di autenticazione dopo aver ottenuto la chiave pubblica del client. Se il server di autenticazione è in grado di verificare che il client desideri connettersi a quell'indirizzo IP del server di gioco, invia che è un client a posto. Il server di gioco dovrebbe quindi consentire al client di connettersi.

La chiave privata viene utilizzata solo per l'autenticazione del client in modo che il server di gioco non ottenga il vero ID di autenticazione.

Ci sono diverse soluzioni che mi vengono in mente, ma qui è la più sicura:

1. il client si collega al server.
2. il client richiede un bridge di autenticazione.
3. il server si connette al server auth, fungendo da proxy tra player e auth. server.
4. client e server di autenticazione, formano una sessione SSL su questo bridge appena formato.
5. usando questa connessione sicura su bridge, il client accede al server di autenticazione.
6. Il server auth indica al server di gioco se l'accesso ha avuto esito positivo o meno, tramite un'altra connessione TCP. quindi disconnette la connessione bridge / login.
7. il client e il server di gioco possono ora riprendere la comunicazione (solo) tramite una connessione già esistente (utilizzata per l'autenticazione).

Si noti che, in questo scenario, il server di gioco in realtà non ha modo di intercettare, anche se l'intera autenticazione lo sta attraversando. per lo stesso motivo il tuo ISP non può monitorare quali pacchetti invii a Facebook o provengono da Facebook.

Il modo in cui lo farei è fare in modo che il server Auth invii il token al client dopo il login insieme all'elenco dei server di gioco convalidati (in modo che il client possa essere sicuro che il server di gioco sia valido).

Quindi il client invia il token al server di gioco, che lo invia al server Auth per confermare che si tratta del client valido.

Accesso:

1. Da client a server Auth: nome utente e password crittografata
2. Server di autenticazione al client: token

Più tardi quando ti unisci a un server di gioco:

3. Da client a server di gioco: il token menzionato in precedenza
4. Server di gioco su server Auth: di nuovo il token
5. Server di autenticazione su server di gioco: se il token è valido, allora segnale OK
6. Game server to Client: consente al client di unirsi

Che ne dite di firmare un token JWT con un segreto che solo l'autorità centrale e il server del giocatore conoscono? Ti consente di firmare json, che può essere verificato in seguito.