Dipendenza circolare nell'architettura dei microservizi per l'autenticazione

Question

Dipendenza circolare nell'architettura dei microservizi per l'autenticazione

#1 da (1 voti)
#2 da (0 voti)

2

Stiamo pianificando di utilizzare OAuth2 / OpenID-connect per l'autenticazione & Autorizzazione e sto guardando quali servizi sarebbero necessari. Finora ho identificato che ho bisogno di un minimo:

Un servizio di autorizzazione OpenID-connect, ad es. implementato utilizzando Identity Server
Servizi per la registrazione e la gestione degli utenti
Servizio / i per la registrazione e la gestione delle applicazioni client

(La mia ipotesi qui è che sto meglio avendo questi come servizi separati piuttosto che raggruppare tutti questi in una sorta di mini-monolite di autenticazione)

Durante la manutenzione delle richieste di autenticazione, Identity Server dovrà cercare l'id del client e potrebbe anche aver bisogno di cercare i dettagli dell'utente. Per me, sembra che la soluzione più semplice sia una richiesta REST / HTTP, ad es. qualcosa di simile (dove la password è contenuta nel corpo)

POST https://users.api/users/justinp/authenticate

Mi sembra anche che voglio che le richieste a questa API vengano autenticate, tuttavia, crea una sorta di dipendenza circolare in base alla quale il servizio di autorizzazione dipende dal servizio utente per soddisfare le richieste, ma il servizio utente (e allo stesso modo il client servizio app) dipendono dal servizio di autorizzazione per l'autorizzazione. Ciò non causa problemi in fase di esecuzione poiché il server delle autorizzazioni può, naturalmente, generare i propri token di autorizzazione validi , ma il design non sembra ancora "abbastanza appropriato".

Riesco a vedere come potrei evitarlo in vari modi, ad es. utilizzando CQRS / Event Sourcing - fare in modo che i servizi delle app degli utenti e dei client spostino le modifiche in modo che il servizio di autorizzazione possa mantenere il proprio elenco interno di utenti e client, tuttavia questa complessità aumenta e non sono del tutto sicuro che sia necessario.

In questo caso, questa "dipendenza circolare" è davvero soddisfacente, oppure questa architettura è un po 'fastidiosa?

microservices oauth2

posta Justin 16.05.2017 - 19:43

fonte

2 risposte

Leggi altre domande sui tag microservices oauth2

Aggiunta di comportamenti ai modelli senza interferenze MVVM, esempio di utilizzo in iOS

score 1 · Answer 1

Prima di fare qualsiasi altra cosa, dovresti leggere questo articolo introduttivo sull'autenticazione HTTP per iniziare.

Il flusso del protocollo Oath2 è mostrato sotto come descritto in Il framework di autorizzazione OAuth 2.0 :

 +--------+                               +---------------+
 |        |--(A)- Authorization Request ->|   Resource    |
 |        |                               |     Owner     |
 |        |<-(B)-- Authorization Grant ---|               |
 |        |                               +---------------+
 |        |
 |        |                               +---------------+
 |        |--(C)-- Authorization Grant -->| Authorization |
 | Client |                               |     Server    |
 |        |<-(D)----- Access Token -------|               |
 |        |                               +---------------+
 |        |
 |        |                               +---------------+
 |        |--(E)----- Access Token ------>|    Resource   |
 |        |                               |     Server    |
 |        |<-(F)--- Protected Resource ---|               |
 +--------+                               +---------------+

                 Figure 1: Abstract Protocol Flow

The abstract OAuth 2.0 flow illustrated in Figure 1 describes the
interaction between the four roles and includes the following steps:

(A)  The client requests authorization from the resource owner.

(B)  The client receives an authorization grant, which is a
     credential representing the resource owner's authorization

(C)  The client requests an access token by authenticating with the
     authorization server and presenting the authorization grant.

(D)  The authorization server authenticates the client and validates
     the authorization grant, and if valid, issues an access token.

Tutti i servizi di risorsa devono essere in grado di convalidare il token. Ci sono "molti modi diversi e validi" per fare OAuth2 ma ti consiglio di utilizzare le firme crittografiche sui token. Quindi i server delle risorse possono convalidare il token senza raggiungere altro. La revoca potrebbe tuttavia costituire una preoccupazione. Raccolgo che inizialmente la specifica del token era specifica del fornitore ma ora esiste uno standard attorno a questo.

Per quanto riguarda il ripristino del nome utente e il ripristino della password, non prenderei in considerazione quella parte del servizio di autenticazione. Lo separerei nel suo stesso processo e insieme di servizi indipendenti dal servizio di autenticazione.

score 0 · Answer 2

Consenti la ricerca di un ID utente o token dal servizio utente senza autenticazione. L'ID utente non è informazioni privilegiate (in un sistema progettato correttamente). Se esporre l'ID utente ti mette a disagio, genera un token utente una tantum che scade dopo un breve periodo di tempo.

Una volta che l'ID utente è autenticato (dal servizio utente o da un servizio di autenticazione separato fornito un ID utente / token e fattori di autenticazione), tutti i servizi dovrebbero funzionare come previsto (incluso il servizio utente).