Flusso di Single Sign-On che utilizza JWT per l'autenticazione tra domini

Sul Web sono disponibili molte informazioni sull'utilizzo di JWT ( Json Web Token) per l'autenticazione. Ma non ho ancora trovato una spiegazione chiara di quale dovrebbe essere il flusso quando si utilizzano i token JWT per una soluzione single sign-on in un ambiente con più domini .

Lavoro per un'azienda che ha molti siti su host diversi. Usiamo example1.com e example2.com . Abbiamo bisogno di una soluzione Single Sign-On, il che significa che se un utente si autentica su example1.com , vogliamo che venga autenticato anche su example2.com , automaticamente.

Utilizzando il flusso OpenId Connect , sono consapevole che l'utente che desidera autenticarsi su example1.com verrà prima reindirizzato al server di autenticazione (o OP: "OpenId Provider"). L'utente si autentica su quel server che quindi lo reindirizza al sito originale example1.com con un token JWT firmato. (Capisco che ci sia un altro flusso che restituisce un token intermedio che a sua volta può essere scambiato per il vero token JWT in seguito, ma non penso che questo sia richiesto per noi) ...

Quindi ora l'utente è tornato su example1.com ed è autenticato! Può effettuare richieste, passando il token JWT in un Authenticationheader e il server è in grado di verificare il JWT firmato e quindi è in grado di identificare l'utente. Bello!

Prima domanda :

Come deve essere archiviato il token JWT sul client? Ci sono, ancora una volta, molte informazioni su questo, e le persone sembrano concordare sul fatto che l'uso Web Storagesia la strada da percorrere piuttosto che il buon vecchio cookies. Vogliamo che il JWT sia persistente tra i riavvii del browser, quindi usiamo Local Storage, non Session Storage...

Ora l'utente può riavviare il proprio browser e sarà comunque autenticato su example1.com , purché il token JWT non sia scaduto!

Inoltre, se example1.com ha bisogno di fare una richiesta Ajax a un altro dei nostri domini, capisco che la configurazione di CORS lo consentirebbe. Ma il nostro caso d'uso principale non sono le richieste interdominio, bensì una soluzione Single Sign-On !

Pertanto, la domanda principale:

Ora, quale dovrebbe essere il flusso, se l'utente va su example2.com e vogliamo che venga autenticato, utilizzando il token JWT che ha già? Local Storagenon sembra consentire l'accesso tra domini, quindi a questo punto il browser non può leggere il token JWT per effettuare richieste a example2.com !

Dovrebbero :

• L'utente viene reindirizzato nuovamente al server di autenticazione ? Quando l'utente si è autenticato per example1.com , il server di autenticazione potrebbe aver impostato un cookie sull'utente, quindi questa nuova richiesta di autenticazione per example2.com potrebbe utilizzare quel cookie per vedere che l'utente è già autenticato e lo reindirizza immediatamente a example2.com con lo stesso token JWT?
• Oppure il browser, su example2.com , può accedere al token JWT senza dover tornare nuovamente al server di autenticazione ? Vedo che esistono soluzioni di archiviazione incrociata , ma quelle sono ampiamente utilizzate? Sono la soluzione suggerita per un ambiente SSO interdominio?

Non vogliamo niente di stravagante, saremmo contenti della soluzione maggiormente utilizzata!

L'utente dovrebbe essere reindirizzato nuovamente al server di autenticazione e ottenere un nuovo token (JWT), uno specifico per example2.com. Ecco come funzionano OpenID Connect e qualsiasi altro protocollo SSO federato tra domini.

Reindirizzare l'utente al servizio di autenticazione centrale quando l'utente non è connesso per richiedere le credenziali ed emettere un nuovo token di autenticazione è lo scenario comune nei sistemi Single Sign On che utilizzano protocolli ben noti come oauth2 o OpenId Connect

Tuttavia, quando questo schema viene utilizzato tra domini, lo svantaggio principale è che l'utente verrà reindirizzato e autenticato ogni volta che naviga in un altro dominio a causa della politica della stessa origine : il token di accesso non può essere condiviso tra domini ( example2.comnon può accedere ai dati di example1.com), quindi il dominio di destinazione tratterà l'utente come non autenticato, reindirizzandolo al servizio SSO centrale.

Per evitare che il servizio di autenticazione richieda nuovamente le credenziali, è comune avere un cookie di sessione (non un token di accesso), ma esiste una tecnica per condividere i dati tra i domini utilizzando il browser localStorage / cookie e un iframe che punta a un dominio intermedio sso.example.com

1. Per autenticare l'utente in example1.com, reindirizzarlo al server di autenticazione in sso.example.com, emettere un JWT dopo l'autenticazione e archiviarlo nel localStorage di questo dominio. Successivamente, reindirizza l'utente al dominio di origine example1.com

2. Crea un iframe example2.compuntando a sso.example.com. L'iframe in sso.example.com legge il token JWT e invia un messaggio alla pagina principale

3. La pagina padre riceve il messaggio e ottiene il token allegato che continua con il flusso SSO

Non ci sono problemi con la politica della stessa origine perché sso.example.comha accesso al suo archivio locale e la comunicazione tra iframe e la pagina principale è consentita se i domini di origine e di destinazione si riconoscono l'un l'altro (vedere http://blog.teamtreehouse.com/cross-domain- messaggistica-con-messaggio )

Per semplificare lo sviluppo, abbiamo recentemente rilasciato un SSO interdominio con JWT su https://github.com/Aralink/ssojwt

Questo metodo è perfettamente compatibile con i flussi SSO. È solo un modo per condividere il token di autenticazione senza reindirizzamenti ed evitare accessi non necessari quando i domini sono federati

Non sono sicuro che questo risponda alla tua domanda, ma se il tuo obiettivo principale è il single sign-on, penso che un semplice proxy inverso risolverebbe il tuo problema (almeno quello di archiviazione interdominio).

Quindi esempio1.com esempio2.com

diventerebbe qualcosa di simile

example.com/example1

example.com/example2

(E dal lato utente, di solito è più pulito)

Se questa non è un'opzione, potresti dover impostare in modo che quando un utente si autentica in 1 dominio, utilizzi iframe AJAX / nascosti per creare un'autenticazione anche con gli altri domini (inviando un token 1 volta tramite URL se devi ).

e se QUESTA non è un'opzione, potresti dover ricorrere a nome utente + pin, poiché i browser stanno diventando più severi sull'interazione tra domini.