Comprendere IAM, OAuth, OpenID Connect, SAML, SSO e JWT in un unico articolo

Il dominio della gestione delle identità e degli accessi (IAM) è diventato più intricato negli ultimi anni. Termini sofisticati come OAuth, OpenID Connect (OIDC), SAML, SSO e JWT sono usati frequentemente, ma cosa significano? Come funzionano insieme? Esploriamo questi concetti e framework per renderli più comprensibili e pratici.

Cos'è l'IAM?#

La gestione delle identità e degli accessi (IAM) è un concetto ampio che implica la gestione delle identità digitali e l'implementazione del controllo degli accessi. I framework e i protocolli menzionati in precedenza rientrano nell'IAM, ciascuno affrontando sfide specifiche in questo spazio.

In sostanza, l'IAM riguarda:

• Identità: Una rappresentazione digitale di un utente, servizio o dispositivo. Un'identità include tipicamente attributi come nome, email, ruoli, ecc., per descrivere l'entità.
• Accesso: La capacità di interagire con le risorse, eseguire azioni o utilizzare servizi. L'accesso definisce quali azioni possono essere eseguite su quali risorse.

Nel diagramma sopra, un utente (identità) vuole eseguire una richiesta GET su un'API (risorsa). Gli attributi dell'utente - nome, email e ruolo - descrivono l'identità.

Autenticazione vs. autorizzazione#

L'autenticazione e l'autorizzazione appaiono spesso insieme nelle discussioni sull'IAM. Chiarifichiamo le loro definizioni:

• Autenticazione: Il processo di verifica del possesso di un'identità. Risponde alla domanda: "Quale identità possiedi?"
• Autorizzazione: Il processo di determinazione di quali azioni un'identità autenticata può eseguire su una risorsa. Risponde alla domanda: "Cosa puoi fare?"

Nell'esempio precedente:

• Prima che l'utente (identità) possa eseguire qualsiasi azione, deve completare il processo di autenticazione.
• Dopo l'autenticazione, il sistema deve determinare se l'utente può eseguire una richiesta GET (azione) sull'API (risorsa), cioè completare il processo di autorizzazione.

---

Armati di questa conoscenza di base, smistiamo gli altri acronimi e protocolli.

OAuth#

OAuth 2.0, comunemente chiamato OAuth, è un framework di autorizzazione che consente a un'applicazione di accedere a risorse protette su un'altra applicazione (tipicamente per conto di un utente).

Ad esempio, immagina di avere un'applicazione web chiamata MyApp che vuole accedere al Google Drive di un utente. Invece di chiedere all'utente di condividere le proprie credenziali di Google Drive, MyApp può usare OAuth 2.0 per richiedere il permesso (autorizzazione) da Google per accedere al Drive dell'utente.

Ecco un diagramma semplificato che illustra il flusso di OAuth:

In questo flusso:

• MyApp è il client (identità) che richiede l'accesso a Google Drive (risorsa).
• L'utente (proprietario della risorsa) concede a MyApp il permesso nel passo 6, completando il processo di autorizzazione.

Un elemento chiave in OAuth 2.0 è il token di accesso, che il client usa per dimostrare l'autorizzazione dell'utente ad accedere alle risorse. Per approfondire, vedi Access token.

OpenID Connect (OIDC)#

OpenID Connect (OIDC) è uno strato di autenticazione costruito sopra OAuth 2.0. Aggiunge funzionalità specifiche per l'autenticazione, come i token ID e un endpoint UserInfo, rendendolo adatto sia per l'autenticazione che per l'autorizzazione.

Se rivisitiamo il flusso di OAuth, aggiungendo OIDC si introduce un ID token. Questo token contiene informazioni sull'utente autenticato e consente a MyApp di verificare l'identità dell'utente.

Scenario di esempio: "Accedi con Google"#

Cambiamo esempio. Se MyApp vuole consentire agli utenti di accedere utilizzando i loro account Google, l'obiettivo si sposta sull'autenticazione piuttosto che sull'accesso alle risorse. In questo caso, OIDC è una scelta migliore. Ecco come appare il flusso OIDC:

Differenza chiave: Oltre a un token di accesso, OIDC fornisce un token ID, che consente a MyApp di autenticare l'utente senza necessitare di ulteriori richieste.

OIDC condivide le definizioni di grant di OAuth 2.0, garantendo compatibilità e coerenza tra i due framework.

SAML#

Security Assertion Markup Language (SAML) è un framework basato su XML per lo scambio di dati di autenticazione e autorizzazione tra le parti. SAML, introdotto nei primi anni 2000, è stato ampiamente adottato negli ambienti aziendali.

Come si confronta SAML con OIDC?#

SAML e OIDC sono funzionalmente simili ma differiscono nei dettagli di implementazione:

• SAML: Usa asserzioni basate su XML ed è spesso considerato più complesso.
• OIDC: Utilizza JSON e JWT, rendendolo più leggero e più adatto agli sviluppatori.

Le applicazioni moderne spesso preferiscono OIDC per la sua semplicità e flessibilità, ma SAML rimane prevalente nei sistemi legacy e nei casi d'uso aziendali.

Accesso singolo (SSO)#

Accesso singolo (SSO) è uno schema di autenticazione che consente agli utenti di accedere a più applicazioni e servizi con un unico set di credenziali. Invece di accedere a ciascuna applicazione individualmente, l'utente accede una volta sola e ottiene l'accesso a tutti i sistemi connessi.

Come funziona il SSO?#

Il SSO si basa su un provider di identità (IdP) centrale per gestire le identità degli utenti. L'IdP autentica l'utente e fornisce servizi come autenticazione e autorizzazione alle applicazioni connesse.

L'IdP può utilizzare protocolli come OIDC, OAuth 2.0, SAML o altri per fornire questi servizi. Un singolo IdP può supportare più protocolli per soddisfare le esigenze diverse delle varie applicazioni.

Esempio di SSO Basato su OIDC#

Esploriamo un esempio di SSO basato su OIDC:

In questo flusso, l'utente accede all'IdP una volta sola ed è autenticato su più applicazioni (AppA e AppB).

SSO aziendale#

Anche se SSO è un concetto ampio, potresti anche incontrare il termine SSO aziendale, che si riferisce a un tipo specifico di SSO progettato per ambienti aziendali (tipicamente per dipendenti e partner).

Quando un cliente richiede SSO per la tua applicazione, è importante chiarire le loro esigenze e i protocolli che stanno utilizzando. Nella maggior parte dei casi, ciò significa che per domini email specifici, vogliono che la tua applicazione reindirizzi gli utenti al loro IdP (che implementa l'SSO aziendale) per l'autenticazione.

Esempio: Aggiunta di un provider di SSO aziendale#

Ecco un esempio semplificato di integrazione di un provider di SSO aziendale (Banana) con la tua applicazione (MyApp):

JWT#

JSON Web Token (JWT) è uno standard aperto definito nella RFC 7519 che consente la comunicazione sicura tra due parti. È il formato standard per i token ID in OIDC ed è ampiamente utilizzato per i token di accesso OAuth 2.0.

Ecco le caratteristiche chiave di JWT:

• Compatti: I JWT sono oggetti JSON codificati in un formato compatto, il che li rende facili da trasmettere e memorizzare.
• Autocontenuti: I JWT contengono tutte le informazioni necessarie sull'utente e sul token stesso.
• Verificabili e cifrabili: I JWT possono essere firmati e cifrati per garantire integrità dei dati e riservatezza.

Un tipico JWT ha questo aspetto:

Questo JWT è composto da tre parti separate da punti:

• Header: Contiene i metadati del token, come il tipo di token e l'algoritmo di firma.
• Payload: Contiene informazioni sull'identità e sul token stesso.
• Signature: Verifica l'integrità del token.

Sia l'header che il payload sono oggetti JSON codificati in base64. Il JWT sopra può essere decodificato come segue:

Usando JWT, il client può decodificare il token ed estrarre le informazioni dell'utente senza dover fare richieste aggiuntive al provider di identità. Per saperne di più sui JWT, visita JSON Web Token (JWT).

Ricapitolazione#

Abbiamo coperto molti aspetti in questo articolo. Riassumiamo i punti chiave con un esempio:

Immagina di avere un'applicazione web, AppA, che richiede una soluzione di gestione delle identità e degli accessi (IAM). Scegli Logto, un provider di identità che utilizza OpenID Connect (OIDC) per l'autenticazione. Poiché OIDC è costruito su OAuth 2.0, Logto supporta anche l'autorizzazione per la tua applicazione.

Per ridurre gli attriti per i tuoi utenti, abiliti "Accedi con Google" in Logto. Questo utilizza OAuth 2.0 per scambiare dati di autorizzazione e informazioni utente tra Logto e Google.

Dopo che l'utente ha effettuato l'accesso a AppA tramite Logto, AppA riceve un token ID, che è un JSON Web Token (JWT) contenente le informazioni sull'utente.

Mentre la tua attività cresce, lanci una nuova applicazione, AppB, che ha anch'essa bisogno dell'autenticazione dell'utente. Poiché Logto è già impostato, puoi riutilizzare lo stesso flusso di autenticazione per AppB. I tuoi utenti possono ora accedere sia a AppA che a AppB con un unico set di credenziali, una caratteristica nota come accesso singolo (SSO).

Successivamente, un partner commerciale ti chiede di connettere il loro sistema SSO aziendale, che utilizza Security Assertion Markup Language (SAML). Scopri che Logto supporta connessioni SAML, quindi imposti una connessione tra Logto e il sistema SSO del partner. Ora, gli utenti dell'organizzazione del partner possono accedere anche a AppA e AppB utilizzando le loro credenziali esistenti.

---

Spero che questo articolo abbia chiarito questi concetti per te. Per spiegazioni più approfondite ed esempi, consulta Auth Wiki. Se stai cercando una soluzione IAM per la tua applicazione, considera l'uso di un servizio gestito come Logto per risparmiare tempo e fatica.