Per gestire l'autenticazione in un'architettura di microservizi, è necessario avere un diverso punto di vista.
Ricordare che quando si lavorava su un monolite, si disponeva di un singolo processo di autenticazione.
Come esempio nell'app PHP, si trova l'utente in un database con le credenziali corrispondenti, quindi è stata creata una sessione a cui l'utente è "autenticato".
Con microservizi, il flusso di lavoro è un po 'lo stesso. L'unica cosa che cambia ora è che non si è in grado di aprire una sessione in servizi diversi. Inoltre, non è necessario ottenere l'utente autenticato. Devi solo essere sicuro di essere autorizzato a eseguire la chiamata corrente sui tuoi microservizi.
Grazie a oauth2, disporre di un access_token valido fornisce queste informazioni.
Questo dovrebbe rispondere alla parte di frontend. Nella parte backend (intendo dietro il gateway API), non devi gestire access_token perché non è rilevante per i microservizi. È possibile utilizzare un tasto funzionale per trovare qualsiasi informazione rilevante per l'utente all'interno di microservizi come un uuid per esempio.
Per ottenere un uuid durante l'utilizzo di oauth2, suggerisco di utilizzare anche openid connect. È utente con questo protocollo per gestire specifiche informazioni utente e ti dà accesso a un endpoint specifico "/ userinfo".
Spero che questo schema renda più chiara questa risposta.

fonte
2017-03-11 10:34:23
Grazie per la risposta. La parte del tuo post che mi interessa davvero è la seconda, quando dici "Puoi farlo nel Gateway o in ogni servizio". Potete dettagliare un po 'di più con pubblicità e contro, per favore? : - D – mfrachet
=> Separiamo l'autorizzazione dall'autenticazione. Il servizio di autenticazione dà "al frontend" "all'utente" un modo per dire "sì, sono io, è la mia sessione". L'autorizzazione dice all'utente X può fare qualcosa o non può. Mentre l'autenticazione viene eseguita da auth service/oauth, ecc., L'autorizzazione può essere collegata a regole aziendali molto più profonde e complesse. Diciamo che Gateway controlla se auth-token è valido e chiama i servizi di avvolgimento con l'intestazione HTTP X-UserId. Ora quei servizi hanno bisogno di se stessi per verificare se l'utente con un determinato ID può fare qualcosa. Ex. if UserId == project.ownerId project.save() –
Quindi il proxy può essere un NGINX che ha qualche script che acceda Redis e controlla se il token è all'interno di redis e passa il valore del token da Redis in un'intestazione a servizi wrapper. Oppure può essere un normale microservizio. Questo può essere stratificato come richiesto, dato un dominio abbastanza complicato. –