Funzionalità OAuth2, microservices e "mantieni il login"

0

Sto cercando di saperne di più sull'autenticazione nei microservizi usando OAuth2.

Ho letto su OAuth2 e, mentre capisco le basi, ho grandi difficoltà a capire come tutto funzioni insieme.

Iniziamo con un esempio:

Ho un sito web, che è costruito su due microservizi:

  • auth service: fondamentalmente un servizio auth2 che utilizza l'autenticazione della password basata sul proprietario delle risorse.
  • album: una volta che un utente è autenticato, può creare album fotografici e condividerlo con altri utenti del sito.
  • Il sito web
  • ha l'opzione "ricordami per 30 giorni" durante il login.
  • l'utente dovrebbe essere in grado di vedere da quali dispositivi e posizioni ha effettuato l'accesso e in grado di terminarli (in caso di accessi non autorizzati). Questo è simile alla funzionalità fornita da FaceBook e DropBox.

Iniziamo con l'app di autenticazione, una tipica risposta auth2 si presenta così:

{"refresh_token": "aEMpqJsg6aotX9HaeVnFqqRBaQn7Bo", "access_token": "aSAX21mzmYRnizwhn1ltFZWDsIbif4", "expires_in": 36000, "token_type": "Bearer", "scope": "read write"}

Il pulsante di accesso del mio sito web fa appena un OAuth2 richiede il mio servizio di autenticazione e riceve la risposta sopra.Ora, cosa devo fare con queste informazioni per poter utilizzare questo? Memorizzo questa risposta JSON in un cookie? Ho bisogno di qualche forma di persistenza, per poter utilizzare questo token per le richieste successive.

Domanda successiva: posso creare un token che scade tra 30 giorni o è considerato una cattiva pratica? Se sì, come posso mitigarlo senza perdere questa funzionalità?

Ora alla parte successiva: il mio servizio di album deve sapere chi è l'utente. Presumo che il gateway API abbia la responsabilità di assicurarsi che il token sia corretto e che includa anche l'id utente nella richiesta? Cosa succede se l'album necessita di ulteriori informazioni sull'utente? Dovrebbe semplicemente contattare l'app di autenticazione per questo?

Ho cercato di trovare da solo le risposte a queste domande, ma è molto difficile trovare informazioni valide al riguardo. La maggior parte delle cose che ho trovato sulla rete mi hanno dato risposte vaghe, come "leggi le specifiche di oauth2" o "usa JWT". Mentre mi rendo conto che è necessaria una buona comprensione di oauth2, sarebbe utile per me ricevere una spiegazione da qualcuno che ha una reale esperienza nella costruzione di qualcosa di simile. (I consigli sui libri sono i benvenuti).

    
posta Jeroen Jacobs 30.07.2016 - 23:43
fonte

2 risposte

2

Innanzitutto, determina se i tuoi servizi sono riservati o meno.

Clients capable of maintaining the confidentiality of their credentials (e.g., client implemented on a secure server with restricted access to the client credentials), or capable of secure client authentication using other means.

Quindi, ad esempio, l'applicazione angolare o l'applicazione mobile di solito non sono riservate, ma i servizi di back-end sono.

Se il tuo servizio è riservato , puoi archiviare in modo sicuro un token di aggiornamento per un periodo piuttosto lungo (ad esempio 30 giorni). Il flusso completo sarebbe:

  1. Registra un client sul server di autorizzazione
  2. Archivia in modo sicuro client_id e client_secret sul tuo servizio

Dopodiché puoi autenticare gli utenti:

  1. Autentica un utente
  2. Ottieni accesso e Aggiorna token
  3. Archivia il token di aggiornamento in modo sicuro
  4. Quando accesstoken è scaduto, procurane uno nuovo con token di aggiornamento

In questo caso hai token di accesso di breve durata e token di aggiornamento a vita lunga .

I token di accesso validi per 30 giorni sono una cattiva pratica, di solito vengono emessi non più di 8-12 ore.

Se il tuo servizio non è riservato , puoi pensare di utilizzare un servizio di periferia o un proxy inverso che gestirà i problemi di archiviazione in modo sicuro.

Riguardo a ottenere l'accesso alle informazioni dell'utente , ti consiglierò di utilizzare OpenID Connect che è in realtà più adatto per scopi di autenticazione. OpenID Connect è un protocollo di autenticazione costruito su OAuth2. Semplificato aggiunge API di identità utente a OAuth.

OpenID Connect aggiunge un token aggiuntivo alla risposta del server di autorizzazione (token ID JWT) con informazioni utente minime e endpoint specificato / userinfo dove il servizio può ottenere informazioni aggiuntive dell'utente .

Per riepilogare i consigli:

  1. Utilizza OpenID Connect per l'autenticazione
  2. Utilizza OAuth per le comunicazioni service-to-service
  3. Archivia in modo sicuro le credenziali del client e reinserisci i token
  4. Utilizza token di accesso di breve durata e token di aggiornamento di lunga durata
risposta data 04.08.2016 - 23:19
fonte
-1

Mi piace molto il JWT su OAuth2 perché JWT è progettato per l'autenticazione e l'autorizzazione. OAuth2 è solo Autorizzazione.

Ignorandolo, entrambi i tipici vengono passati ai servizi allo stesso modo usando le intestazioni, ad esempio

POST https://your.website.com/api HTTP/1.1
//Other Header informaiton
Authorization: Bearer <Token>

Il server leggerà il token e lo confronterà con quello che ha sul file e lo consentirà / negherà in base a ciò. Se hai bisogno di maggiori informazioni su Architecting a Secure Web Service, ti suggerisco un Programmers.SE, per domande di codifica specifiche Stackoveflow.SE.

Modifica: risponde ad altre domande.

Tipicamente i token sono memorizzati in cookie con il flag di sicurezza (solo HTTPS), ma devi comunque stare attento a cose come CSRF.

Suggerisco di leggere il link . Il team di stormpath ha un sacco di buone informazioni in merito a tutte le tue domande, e anche ai video di YouTube, che approfondiscono discussioni e dimostrazioni. Non ho mai usato i loro servizi, ma ho imparato molto da loro. Si concentrano principalmente su JWT, ma discutono e lavorano con OAuth2.

    
risposta data 05.08.2016 - 00:12
fonte

Leggi altre domande sui tag