Microservice - Oauth2 Flusso di lavoro con SPA, accesso a Facebook e JWT

Introduzione

Al momento stiamo cercando di capire come implementare l'autenticazione basata su token e con Facebook Connect in combinazione con forse JWT all'interno dell'architettura dei servizi micro.

Contesto di sistema

1. Applicazione SPA - Una semplice applicazione a pagina singola che sarà ospitata da qualche parte su un CDN.

2. Microservices - Ogni singolo servizio verrà scritto in base all'architettura dei microservizi. Uno di questi servizi sarà il servizio utente che gestirà tutte le informazioni relative all'utente (ad esempio token, informazioni utente)

Requisiti

1. L'utente dovrebbe essere in grado autenticare contro i nostri servizi con un token di accesso di Facebook. In futuro potremmo anche integrare ulteriori parti dell'API del grafico di Facebook, nel qual caso avremmo anche bisogno del token di accesso.

2. Dovrebbe esserci un meccanismo per autenticare e autorizzare un utente su qualsiasi microservizio. Più servizi verranno chiamati in sequenza, in modo da supportare alcuni tipi di concatenamento (ad esempio OAuth per conto di ).

Alcune idee su un possibile flusso

1. Facebook Connect SDK - Autentica contro Facebook che in seguito consentirebbe anche possibili chiamate al grafico api.

2. Token di accesso utente : l'utente recupera un token di accesso di breve durata da Facebook e lo invia al nostro servizio utente.

3. Verifica servizio utente : il servizio utente verifica il token di accesso su Facebook.

4. La verifica del servizio degli utenti riesce - Il servizio utente richiede un token di accesso a lunga durata dal token di accesso di breve durata predefinito che Facebook ha generato. Questo token dovrebbe essere valido per 60 giorni.

5. Voce DB servizio utente : l'hash del token di accesso a lunga durata è memorizzato nel database. Non vedo alcun motivo particolare per cui avrei bisogno in assenza dell'utente del token e quindi eviterei il potenziale rischio di un token di accesso compromesso. Non ho riflettuto molto sullo schema del database, ma stavo pensando a qualcosa su tre tabelle Account , Login e Claim per memorizzare i dati specifici di accesso. Mentre ogni relazione sarebbe 1:n . L'hash verrebbe archiviato nella tabella Login per il provider di Facebook.

6. Servizio utente e amp; JWT : il servizio utente crea un nuovo JWT da tutte le rivendicazioni relative a questo particolare Account . Potrebbero esserci anche altri Logins / Claims da altri fornitori che non faranno parte di ciò che verrà pubblicato da Facebook (ad esempio, l'amministratore Login con le attestazioni corrispondenti). Inoltre, aggiungi anche il token di accesso di Facebook di lunga durata al JWT.

7. Salva JWT - Invia di nuovo il JWT appena creato al client e memorizzalo all'interno di local o session storage . A questo punto il token di accesso già esistente da Facebook nel cookie potrebbe essere cancellato presumo?

8. Facebook SDK - In qualche modo dire all'SDK di Facebook che dovrebbe ora controllare il JWT nella memoria locale per quanto riguarda il token di accesso di Facebook. Se uno qualsiasi degli altri servizi riceve una richiesta, si verifica quanto segue JWT è ricevuto da alcuni servizi casuali. Il token JWT che contiene il token di accesso di Facebook sarebbe molto influenzato dalla crittografia a chiave pubblica che eviterebbe un'ulteriore richiesta al servizio utente. Se il token JWT è scaduto, l'intera catena di servizi fallisce e l'utente viene reindirizzato alla pagina di accesso di Facebook dalla SPA e l'intero flusso ricomincia.

Miglioramenti e amp; Commenti

Sono quasi sicuro di aver trascurato alcune delle cose chiave e per questo motivo apprezzerei qualsiasi aiuto in merito ai possibili miglioramenti. Gradirei anche che tu fossi un feedback se ciò potesse essere fatto in qualche modo più facile e in un modo più sicuro. Per la maggior parte delle parti dell'implementazione, faremmo affidamento su librerie allo stato dell'arte e non scriveremmo nulla da soli.