Come viene autenticato un utente sul server B se sono già autenticati sul server A tramite OAuth2?

1

Diciamo che ho il server A (un server web). Gli utenti inizialmente utilizzano un provider esterno come Google per essere autenticati su quel server. Nel mio database viene creata una voce che dice che questo utente ha effettuato l'accesso prima e ha confermato il proprio account. Ora hanno accesso a risorse come un forum disponibile dal server web (quindi essenzialmente abbiamo creato un account locale per loro).

Ora, l'utente vuole essere autenticato sul server B (un server di gioco). Il server B è accessibile tramite un'app desktop (client di gioco) tramite TCP. Inoltre, disponiamo di un gate server C che gestirà le richieste iniziali dei client desktop prima di poter connettersi al server B.

La voce creata precedentemente per quell'utente, è necessaria per accedere al server B e / o C. Quindi, l'app desktop dovrebbe aprire un browser per autenticare il nostro utente sul server A.

Qual è il flusso generale richiesto per implementare un tale sistema? Il mio punto di confusione è anche se il server C sa che l'utente è autenticato (scambiando i token di accesso con il server A), quali informazioni passiamo al client desktop e al server B così quando il client si disimpegna dal server C, possono essere sicuri del server B non rifiuterà il loro tentativo di connessione (supponendo che la richiesta sia legittima)?

    
posta Alluring Topaz 20.10.2017 - 03:48
fonte

1 risposta

0

Per prima cosa definirei tutti i ruoli di tutti i nodi che hai. Osservando la tua architettura, pretenderei che gate Server (C) funga da gateway API di autorizzazione che è responsabile della gestione dei token necessari per tutte le autenticazioni e autorizzazioni. WebServer (A) e GameSever (B) sono le risorse che richiedono l'accesso dell'utente autorizzato (utilizzando token di accesso OAuth2 o altro JWT)

Definirei il flusso in questo modo:

  1. L'utente apre il desktop del client che lo indirizza all'accesso tramite Google account.
  2. Le risposte di Google con token di identità (cioè token JWT) e il client desktop inviano a Gate Server (C) con le informazioni del suo client_id e della risorsa a cui desidera accedere (in forma di ambiti - cioè game_server)
  3. Il server Gate API (C) di autorizzazione utilizza il token di identità e crea un token di accesso (o un altro token di autorizzazione in forma di JWT) e lo invia al desktop del cliente che lo salva in modo sicuro.
  4. Ad ogni chiamata a Game Server (B) Client Desktop invia il token di autorizzazione e server di gioco controlla che autorizzi il file richiesta.

La cosa importante qui è che devi conservare il token di autorizzazione in modo sicuro sul lato client. Non è facile, quindi ti consiglio di utilizzare qualcosa come un token di riferimento. Su questa soluzione, dopo che Game Server (B) ottiene il token di autorizzazione, deve inviarlo all'API di autorizzazione per ottenere il contenuto del token (attestazioni). Quindi, in questo caso, ogni richiesta da Client Desktop a Game Server (B) risulta in una richiesta aggiuntiva da Game Server (B) a Gateway API di autorizzazione (C).

    
risposta data 20.10.2017 - 10:41
fonte

Leggi altre domande sui tag