come dice @ user454322, cerca la specifica OAuth2 ... è uno standard ampiamente utilizzato e ben supportato che funzionerà bene.
Esistono (in modo basico) 2 modi per distribuire un server di autorizzazione:
1) Come proxy inverso (come mostrato nel diagam di @ user454322). Questo è quando tutte le richieste dall'esterno passano attraverso il server OAuth2 e quindi i tuoi servizi. Ciò centralizza il problema dell'autorizzazione, in modo che venga gestito prima che qualsiasi richiesta raggiunga i servizi. Equivale a terminare SSL nel servizio di bilanciamento del carico. In sostanza, il server di autorizzazione diventa parte del middleware di rete, come i firewall e i bilanciatori di carico.
- lo svantaggio principale è che l'implementazione di un proxy inverso può essere complicato, specialmente se si dispone di payload di grandi dimensioni o se si stanno facendo cose intelligenti con HTTP (HTTP inizia in modo semplice, ma ci sono molte complicate rughe che aggiunge)
- puoi acquistare soluzioni di "gestione API" che forniscono funzionalità di proxy inverso, ma aggiungi cose come OAuth, metriche, limitazione, ecc.
2) Come server di autorizzazione. Questo è un layout leggermente diverso, in cui ogni servizio accetta le richieste direttamente (dai bilanciatori del carico, ecc.) Ogni richiesta viene fornita con un token di accesso nell'intestazione. Il servizio effettua quindi una chiamata HTTP al servizio di autorizzazione per convalidare il token. Il server di autorizzazione è responsabile dell'autenticazione degli utenti e della concessione di token in primo luogo, i tuoi micro-servizi non devono fare quella parte.
- lo svantaggio principale è che ogni richiesta in entrata deve effettuare un round trip sul servizio auth. Ciò aumenta la tua latenza.
- uno svantaggio secondario è che devi assicurarti che ogni dei tuoi servizi chiami il servizio auth - altrimenti, qualsiasi servizio non sarà aperto a Internet e non protetto.
