Microservices: token di accesso esterno archiviati nel servizio di identità, nel servizio di calendario o in entrambi?

0

Sto creando un'applicazione che, finora, ha un servizio di identità (utilizzando identityserver4), un front-end e un servizio di calendario.

L'utente accede tramite terze parti (ad esempio, google) e concede le autorizzazioni all'applicazione per gestire il proprio calendario.

Quando l'utente esegue l'accesso, identityserver memorizza i token di accesso e aggiornamento in AspNetUserTokens.

La domanda:

The calendar service needs access to do background tasks while the end user is offline. Should the access and refresh tokens be stored on the calendar service as well as the identity service?

    
posta ChickenMilkBomb 06.02.2018 - 16:27
fonte

1 risposta

2

Dovresti creare un tuo id per l'utente e usarlo per richiedere i token dal server ID.

Se memorizzi quei token in più servizi, avrai più aggiornamenti da aggiornare sulle scadenze e altre modifiche di tali token. Memorizzali in un punto e fai in modo che altri servizi li richiedano.

Ciò consente anche di effettuare il controllo dell'autorizzazione su quali servizi possono accedere ai token per attività di terze parti applicando il controllo ACL sulle richieste di servizio token.

Il tuo servizio di calendario chiede un token, il servizio token dice "Ecco le informazioni di sistema di terze parti e il token per accedervi". Il tuo servizio di segnalazione richiede un token per Google Calendar, il servizio token dice "No, kthxbai" perché non dovrebbe accedere a tali informazioni. È quindi possibile controllare facilmente tutte le richieste di accesso alle risorse di terze parti da parte degli utenti, semplicemente registrando un registro di controllo dal servizio token. Questo tipo di auditing è davvero fantastico da avere per sicurezza.

Con la centralizzazione dell'archiviazione di token di terze parti a un singolo servizio, ottieni un sacco di vantaggi nel possedere tali importanti informazioni sugli utenti privati in un'unica posizione: diventa più facile da proteggere, più facile da monitorare, più facile da mantenere aggiornato, più facile per pulire le richieste degli utenti. È la soluzione migliore e ti incoraggio a monitorare con attenzione gli utenti di questo servizio per assicurarti che nessuno scriva client che mantengono o memorizzano localmente tali informazioni. In alternativa, rendere il servizio token come un proxy di richiesta in modo che il token non sia reso disponibile anche esternamente. In ogni modo, però, tieni i token privati in un unico posto (crittografati! Protetti! Non eseguire il backup!).

    
risposta data 06.02.2018 - 17:15
fonte

Leggi altre domande sui tag