Come funziona il server di autorizzazione su Single Sign on?

Auth server will also store the token in browser?

In breve, sì. Il cookie del browser e l'archiviazione locale vengono archiviati in modalità sandbox dal sito Web. Quindi, per impostazione predefinita domain2 non può utilizzare il token di domain1. Quindi durante il processo di autenticazione, il browser deve reindirizzare al sito Web del server di autenticazione. Il server di autenticazione esegue l'autenticazione o recupera l'ultimo token di autenticazione dalla memoria del browser. Una volta emesso il token, il server di autenticazione reindirizzerà nuovamente il dominio richiedente con il token auth come parte della richiesta di reindirizzamento.

In altre parole, domain1 e domain2 non possono condividere un token dalla memoria del browser, quindi il server di autenticazione funge da intermediario fidato e passa il token tra i siti.

If so, what is the amount of time the auth server needs to be holding the token?

Probabilmente il server di auth non contiene una copia del token, se stiamo parlando di JWT. Il tuo browser può conservarlo in un cookie o in una memoria locale, e questo è soggetto alle politiche di archiviazione del browser. Poiché i token di autenticazione sono firmati crittograficamente, non è necessario che il server stesso ne conservi una copia. I token includono invece una firma crittografica che può essere convalidata come autentica senza consultare il server di autenticazione. In caso contrario, il server di autenticazione diventa un collo di bottiglia. Una volta che il token è stato convalidato, i contenuti possono essere considerati attendibili. I contenuti del token includono cose come:

• quando scade il token
• chi ha richiesto il token
• quali operazioni sono consentite

Se i dati del token vengono modificati, la firma non corrisponderà più ai contenuti del token e le richieste che utilizzano un token non valido verranno rifiutate.

Doesn't the token stored in auth server be invalid after sometime?

Il token ha una scadenza al suo interno. Il client può esaminare questa scadenza e il server e se la scadenza è scaduta, il client può reindirizzare a un accesso. Se il client tenta di utilizzare il token scaduto, il server rifiuterà la richiesta.

How is it refreshed?

I client parzialmente o completamente fidati possono utilizzare i token di aggiornamento. Questi sono diversi dai token di accesso che sono stati precedentemente descritti. Non concedono l'accesso alle risorse. Invece, concedono al client la possibilità di chiedere al server di autenticazione un nuovo token di accesso senza forzare l'utente a riautenticare.

Generalmente il processo va:

• Il client inizia a fare una richiesta API, esamina il token di accesso
• Token di accesso trovato scaduto
• Il client invia il token di aggiornamento al server di autenticazione, richiedendo il nuovo token di accesso
• Al client viene fornito un nuovo token di accesso
• Il client invia una richiesta API con un nuovo token di accesso

I token di aggiornamento possono essere richiesti quando l'utente si autentica. I token di aggiornamento hanno generalmente un tempo di scadenza lungo, ma i token di accesso emessi da loro hanno un breve periodo di scadenza. Ciò consente al server l'opportunità di revocare le autorizzazioni e di avere quello riflesso nel token di accesso successivo.

Come @Harry Ninh ha detto nei commenti che la scadenza del token tende ad essere una questione delle vostre esigenze, la maggior parte dei sistemi vi permetterà di configurarlo e la sua durata potrebbe essere qualsiasi cosa tra un paio di minuti e per sempre. Anche la maggior parte dei sistemi ha un metodo di aggiornamento dei token: può essere automaticamente dopo ogni utilizzo del token, considerando il tempo di scadenza del token dall'ultima volta in cui è stato utilizzato; oppure può essere un metodo di aggiornamento dei token esplicito. Se dovessi scegliere, andrò per il primo metodo, ma questa è solo un'opinione.

Infine, ma non meno importante, molti sistemi hanno anche un metodo di revoca token che può essere invocato per invalidare immediatamente il token.

If so, what is the amount of time the auth server needs to be holding the token?

Questo dipende interamente dall'implementazione del token che stai per. Le JWT per un esempio sono stateless e non necessitano di alcuna informazione memorizzata su un server nella loro implementazione di base. Con un token con stato ti consigliamo di tenerlo leggermente più lungo della durata del token per assicurarti di poter sempre abbinare un token ancora valido.

Se un token è stato revocato, tramite un metodo di revoca o perché è scaduto, è possibile rimuovere questo token dal server che lo memorizza in quanto ciò significherebbe che non può più essere utilizzato per l'autorizzazione.

Doesn't the token stored in auth server be invalid after sometime?

Sì, tutte le soluzioni che ho visto contenevano un timestamp che diceva quando il token scade. A questo punto il token non è più valido per l'autorizzazione dell'utente.

How is it refreshed?

Questo dipende dalla tua implementazione; come @Zalomon menzionato un modo comune è quello di implementare un metodo di aggiornamento dei token. Generalmente genera un nuovo token, ne utilizza uno esistente per l'autorizzazione e invia il nuovo token indietro per sostituire il vecchio.

Un altro modo è ovviamente quello di far scadere la sessione di un utente con il token e costringerli ad accedere di nuovo

Pensa a Auth Server come a un sito web completamente normale che ha un modo completamente standard per autenticare gli utenti, ad esempio:

• Ha un database di nomi utente e password
• Utilizza l'autenticazione NTLM / Kerberos
• ecc ...

Come qualsiasi altro sito web standard, se qualcuno accede con un nome utente e una password probabilmente vorrai una sorta di cookie per ricordare quell'utente sulle richieste future, e come qualsiasi altro sito web la scadenza ecc ... di quel cookie dipenderà da requisiti (es. sessione scorrevole di 20 minuti, cookie persistente di 3 mesi)

Il routing SSO / auth token interviene solo quando viene coinvolto il dominio1 e vuole essere in grado di eseguire il meccanismo di autenticazione Auth Server. Lo scopo del token di autenticazione è quello di consentire ad Auth Server di comunicare a domain1 chi è l'utente autenticato in modo sicuro .

Auth Server will also store the token in browser?

Se lo desidera, ma non è necessario: qualsiasi meccanismo (ad esempio un cookie) che permetta al server di autenticazione di tracciare l'utente autenticato è corretto, ad es. nel caso di autenticazione di Windows ogni richiesta viene autenticata. Finché il server di autenticazione sa chi è autenticato, può creare token di autenticazione ogni volta che lo desidera, quindi non ha bisogno di memorizzare i token stessi.

Si noti che anche domain1 non deve salvare il token - può farlo, ed è una cosa abbastanza comune da fare, ma sarebbe altrettanto valido scrivere un cookie ASP.Net standard con la stessa scadenza e username come token di autenticazione. Una volta che domain1 sa chi è l'utente autenticato, il token auth ha raggiunto il suo scopo.

How is it refreshed?

Tipicamente il server di autenticazione emetterà i token che scadono prima che i propri cookie vengano eseguiti, ad esempio supponiamo che il server di autenticazione tenga gli utenti loggati per 7 giorni, potrebbe voler rilasciare token che durano per 12 ore. Lo scenario potrebbe apparire un po 'come questo

• Lunedì mattina l'utente accede a domain1 e accede tramite Auth Server. Auth Server scrive un cookie che dura 7 giorni e invia domain1 un token che scade tra 12 ore. domain1 salva anche un cookie, ma questo dura 12 ore. Ciò significa che l'utente può continuare a utilizzare domain1 per il resto della giornata.
• Martedì l'utente torna a domain1 e il cookie per domain1 è scomparso in modo che vengano indirizzati al server di autenticazione, ma il token di 7 giorni dal server di autenticazione è ancora lì, quindi l'utente viene registrato direttamente e un token di autenticazione inviato direttamente al dominio1: tutto ciò che l'utente vede è che la pagina si aggiorna automaticamente un paio di volte.

Quindi il "meccanismo di aggiornamento" per domain1 è solo per autenticare nuovamente il server di autenticazione. Se la durata del token è breve e lo "sfarfallio" dell'aggiornamento della pagina non è desiderabile, puoi utilizzare trucchi come eseguire questo processo in un iframe nascosto.

Nota che Auth Server ha la possibilità di scrivere nuovi cookie ogni volta che l'utente visita quel dominio (ricorda, è solo un normale sito web). Ciò significa che il server di autenticazione può anche "aggiornare" la sua sessione, ad es. facendo scadere i 7 giorni una scadenza di sette giorni.

Un token al portatore / asserzione JWT / SAML / altro artefatto utilizzato in un sistema SSO rappresenta una rivendicazione verificata, verificabile, autorevole del diritto di un utente specifico, con durata temporanea. JWT ha un tempo di scadenza (ad esempio expires_in = 3600 secondi), mentre un'asserzione SAML ha un tempo di scadenza timbro (ad esempio Not on or after = 2017-06-20 11:38:01 ).

A parte questo, tutto è molto generale. La rivendicazione del diritto potrebbe essere qualsiasi cosa: appartenenza a un ruolo, accesso a una risorsa, ecc.

Due approcci generali

Ci sono due modi in cui ho visto questo tipo di meccanismo utilizzato in un contesto di autenticazione:

1. L'asserzione / token / artefatto rappresenta il diritto di accedere a un sistema.

In questo caso, il token del server di autenticazione ha essenzialmente una durata di lunga durata (ad esempio 20-40 minuti) e funge da cookie di sessione multi-dominio. Quando è vicino alla scadenza, dovresti tornare al server di autenticazione per farlo "aggiornato" o "rinnovato" e potresti finire per ottenere un token nuovo di zecca come risultato.

In alcuni sistemi, l'operazione di aggiornamento richiede un round trip al server di autenticazione nel browser stesso . In altri, può essere realizzato tramite il servizio web sul back-end. Quest'ultimo è meno "puro" di un'implementazione (idealmente, solo il server di autenticazione dovrebbe essere in grado di distribuire token) ma in determinate circostanze è necessario mantenere le cose più pulite per l'utente finale: può essere molto fastidioso prendere il browser da qualche altra parte, anche temporaneamente.

2. Il token rappresenta il diritto di avviare l'accesso a un sistema

In questo caso, il server di autenticazione emette un token di durata relativamente breve (ad esempio, 60 secondi) e il server di dominio utilizza questo token come una sorta di password nel proprio meccanismo di gestione delle sessioni. Il server di dominio emetterebbe quindi il proprio cookie di sessione e il token del server di autenticazione non sarebbe più necessario. Il server di dominio dovrebbe essere responsabile dell'aggiornamento di tutti i cookie di sessione, che di solito è molto banale perché questo genere di cose è incorporato nelle piattaforme web, ad es. Autenticazione moduli ASP.NET.

Il lato negativo di questo approccio è che non è un vero SSO ... non puoi navigare senza problemi da un dominio all'altro senza tornare al server di autenticazione per ottenere un nuovo token per avviare una nuova sessione specifica per il dominio. Ma il lato positivo è che è molto più semplice da implementare.

Quindi ... devi aggiornare?

Sì, ma a seconda del modo in cui hai architettato le cose, potresti aggiornare il token emesso dal server di autenticazione oppure potresti aggiornare un token proprietario del dominio, l'ultimo dei quali è banale.

C'è un altro modo per farlo che non richiede il server di autenticazione "middle man", a patto che domain1 e domain2 si fidano l'un l'altro. Puoi utilizzare la crittografia a chiave pubblica o un segreto condiviso di tua scelta per firmare i token Bearer JWT e utilizzare quei token per ottenere un token di accesso per l'altro dominio.

Oserei dire che includere il server di autenticazione di middle man è eccessivo per molti sistemi. Dovresti, come pratica generale, massimizzare la quantità di lavoro non svolto.