Gestione dell’identità: SAML vs. OAuth2 vs. OpenID Connect

Tutto è iniziato con le organizzazioni che avevano bisogno di un modo per centralizzare i loro sistemi di autenticazione per una migliore gestione e sicurezza. È qui che è entrato in gioco il Single Sign On (SSO). Single sign-on (SSO) è una sessione centralizzata e un servizio di autenticazione utente in cui un set di credenziali di accesso può essere utilizzato per accedere a più applicazioni. La sua bellezza è nella sua semplicità; il servizio vi autentica su una piattaforma, permettendovi di accedere in modo trasparente a diversi servizi interni senza dover entrare e uscire ogni volta.

Poi arrivarono gli sviluppatori di app di terze parti che volevano utilizzare le API interne per integrarlo con i loro prodotti e soluzioni, questo era chiaramente una sfida. Poi sono arrivati i social network e hanno reso le cose ancora più complicate, attualmente abbiamo migliaia di app che supportano l’autenticazione attraverso i social network come Facebook, Google, Twitter, LinkedIn, ecc. Il problema in queste architetture è la sfida di mantenere le cose il più semplice possibile e aumentare la sicurezza allo stesso tempo. La soluzione? Identità federate.

Al momento, i tre principali protocolli per l’identità federata sono: SAML, OAuth2 & OpenID Connect. Prima di immergerci in profondità in questi tre protocolli, discutiamo alcuni concetti comuni che la gente tende a confondere.

Quando si tratta di sicurezza e accesso, autenticazione & autorizzazione sono due termini che la gente tende a trascurare e spesso vengono scambiati per significare la stessa cosa. Ebbene, l’autenticazione è la verifica della vostra identità mentre l’autorizzazione è la verifica di ciò a cui avete accesso.

L’autenticazione è la convalida delle credenziali di accesso prima di dare all’utente l’accesso al sistema. Quando si tratta di sicurezza, si raccomanda di utilizzare almeno due fattori di autenticazione prima di concedere all’utente l’accesso a qualsiasi cosa. (2FA, MFA, token digitali & fisici, ecc.)

L’autorizzazione avviene dopo il processo di autenticazione, verificando i tuoi diritti prima di concederti l’accesso alle risorse richieste, come database, file, repository, ecc. Un esempio pratico potrebbe essere una volta che i login di un dipendente sono stati verificati, è vedere a quali piani ha accesso.

Entrambe le autorizzazioni & l’autenticazione sono cruciali per la sicurezza e la gestione degli accessi e anche se entrambi hanno concetti diversi dietro di loro, sono un elemento critico per l’infrastruttura di un sistema e la loro comprensione è fondamentale per la gestione delle identità e degli accessi.

SAML

Security Assertion Markup Language (SAML) è uno standard aperto basato su XML usato per implementazioni SSO (Single Sign On). SAML 2.0 è stato rilasciato nel 2005 ed è la versione attuale dello standard.

SAML è usato sia per l’autenticazione & che per l’autorizzazione tra due parti: un Service Provider (Office365, Salesforce, G Suite, ecc.) & un Identity Provider (Okta, OneLogin, Ping Identity, ecc.). Il Service Provider (SP) accetta di fidarsi dell’Identity Provider (IdP) nel processo di autenticazione. Questo avviene attraverso un documento SAML XML inviato dall’IdP contenente l’autorizzazione dell’utente & autenticazione e poi reindirizzato al fornitore di servizi.

Consideriamo questo esempio:

• Identity Provider (IdP): Okta
• Service Provider (SP): Applicazione Salesforce

1. L’utente cerca di accedere all’applicazione Salesforce della sua azienda da Chrome.
2. L’applicazione Salesforce risponde generando una richiesta SAML
3. Chrome reindirizza l’utente a un URL SSO, Okta analizza la richiesta SAML, autentica l’utente (questo potrebbe essere tramite nome utente e password, autenticazione a due fattori o MFA se l’utente non è sulla rete interna della società; se l’utente è già autenticato su Okta, questo passaggio sarà saltato) e genera una risposta SAML.
4. Okta reinvia la risposta SAML codificata a Chrome
5. Chrome reindirizza la risposta SAML all’applicazione Salesforce
6. Se la verifica ha successo, l’utente verrà loggato nell’applicazione Salesforce e gli verrà concesso l’accesso a tutte le varie risorse.

OAuth2

“Come posso permettere ad un’app di accedere ai miei dati senza necessariamente dargli la mia password?”

OAuth2 è uno standard aperto utilizzato per l’autorizzazione, permette alle app di fornire all’applicazione “autorizzazione delegata”. A differenza di altri framework che forniscono autenticazione, OAuth autorizza solo dispositivi, API, server con token di accesso piuttosto che credenziali e funziona su HTTPS.

Se avete mai visto una delle finestre di dialogo qui sotto, è di questo che stiamo parlando. Questa è un’applicazione che chiede se può accedere ai dati per conto vostro. Questo è OAuth.

Si può pensare a questo come alle key card degli hotel, ma per le applicazioni. Se hai una tessera dell’hotel, puoi ottenere l’accesso alla tua stanza. Come si fa ad avere una key card d’albergo? Devi fare un processo di autenticazione alla reception per ottenerla. Dopo essersi autenticati e aver ottenuto la key card, si può accedere alle risorse dell’hotel.

OAuth definisce quattro ruoli:

• Proprietario della risorsa: generalmente l’utente stesso
• Cliente: Applicazione che richiede l’accesso ad un server di risorse
• Server di risorse: Server che ospita dati protetti (per esempio Facebook che ospita il tuo profilo e le tue informazioni personali)
• Server di autorizzazione: Server che rilascia un token di accesso al client. Questo token sarà usato dal client per richiedere il server delle risorse.

Di seguito un diagramma del flusso OAuth2.

Consideriamo questo esempio:

1. Spotify vuole accedere alla vostra lista di amici dal vostro account Facebook.
2. Si viene reindirizzati da Spotify al server di autorizzazione (Facebook in questo caso)
3. Se si autorizza l’accesso, il server di autorizzazione invia un codice di autorizzazione al client (Spotify) nella risposta di callback.
4. Quindi, questo codice viene scambiato con un token di accesso tra Facebook e Spotify.
5. Ora Spotify è in grado di utilizzare questo token di accesso per interrogare il server delle risorse (Facebook) e recuperare la vostra lista di amici.

Una cosa da notare è che l’utente non vedrà mai il token di accesso, sarà memorizzato nella sessione. Il server di autorizzazione invia anche altre informazioni come la durata del token e un token di aggiornamento.

OpenID Connect

OpenID Connect è un semplice livello di identità sopra il protocollo OAuth 2.0 che estende OAuth2 e permette la ‘Federated Authentication’.

Il flusso del processo di OpenID Connect è simile al flusso di autorizzazione di OAuth2 con la differenza principale che è un ‘id-token’ che permette l’autenticazione dell’utente.

Nota che l’autenticazione federata è completamente diversa dall’autorizzazione delegata. Prendiamo di nuovo l’esempio di Facebook e Spotify

• L’autenticazione federata è l’accesso a Spotify usando le vostre credenziali di Facebook.
• L’autorizzazione delegata è la capacità di un’app esterna di accedere alle risorse. In questo caso, Spotify cerca di accedere alla vostra lista di amici di Facebook per importarla in Spotify.

Per concludere, ecco una tabella che riassume tutti e tre i protocolli/frameworks.