Italiano

auth
authentication
oauth
oidc
identity

Perché JWT nella maggior parte dei servizi OAuth 2.0

Questo articolo spiega perché JWT è ampiamente adottato come formato per i token di accesso in OAuth 2.0, evidenziando i suoi vantaggi e le sue limitazioni.

Yijun

Developer

9/11/2023

Smetti di sprecare settimane sull'autenticazione degli utenti

Lancia app sicure più velocemente con Logto. Integra l'autenticazione degli utenti in pochi minuti e concentrati sul tuo prodotto principale.

Inizia ora

OAuth 2.0 è ampiamente utilizzato oggi. Come framework centrale per i servizi di autorizzazione, una delle principali responsabilità di OAuth 2.0 è emettere token di accesso per gli utenti. Abbiamo notato che molti fornitori di servizi OAuth sul mercato emettono token di accesso nel formato JWT.

In questo articolo, introdurremo cos'è JWT e perché è ampiamente adottato come formato per i token di accesso emessi da OAuth 2.0.

Introduzione a JWT

JWT sta per JSON Web Token ed è definito da RFC 7519 come segue:

JSON Web Token (JWT) è un mezzo compatto e sicuro per rappresentare affermazioni da trasferire tra due parti.

Questa definizione chiarisce che JWT è un token utilizzato per passare affermazioni tra diverse parti.

Poiché i JWT sono passati tra più parti, sono firmati per garantire l'integrità e l'autenticità dei dati.

Un JWT firmato ha il seguente formato:

Consiste di tre parti separate da .: l'header, il payload e la firma.

Ecco un esempio di un JWT reale:

Puoi provare a decodificarlo su https://jwt.io:

Come mostrato nell'immagine, la sezione header del JWT contiene informazioni sull'algoritmo di firma utilizzato e sul tipo di token. La sezione payload contiene le affermazioni trasportate dal JWT e la signature è utilizzata per verificare l'integrità del JWT.

Ora che abbiamo compreso cos'è il JWT e il significato delle sue diverse parti, procediamo a spiegare perché molti servizi di autorizzazione OAuth scelgono il JWT come token di accesso.

Vantaggi dell'uso di JWT

Le distinzioni chiave tra JWT e i token tradizionali basati su stringhe casuali sono che i JWT possono trasportare informazioni e possono essere convalidati tramite decodifica. Queste differenze portano due vantaggi significativi:

Efficienza delle risorse: i JWT possono trasportare informazioni sull'utente o sulla sessione, eliminando la necessità di frequenti ricerche nel database. Questa efficienza può ridurre il consumo di risorse dei servizi.
Migliorata disponibilità e scalabilità: i JWT riducono la dipendenza dalla gestione dello stato lato server. Ciò consente ai servizi di essere più stateless, migliorandone la disponibilità e la scalabilità.

Quando si utilizzano token tradizionali basati su stringhe casuali, il processo tipico di verifica e autenticazione è il seguente:

Come mostrato nel diagramma, quando un sistema ha numerosi utenti e molti diversi Server di Risorse, può risultare in numerose richieste di validazione token al Server di Autenticazione.

Nel tempo, man mano che il sistema cresce, il Server di Autenticazione può facilmente diventare un collo di bottiglia, rappresentando una sfida per la disponibilità complessiva del servizio.

Tuttavia, quando vengono introdotti i JWT, il processo di validazione cambia in:

Grazie alla funzionalità dei JWT che consente la validazione tramite decodifica, il Server di Risorse può verificare l'integrità dei JWT ed estrarre le informazioni utente da essi senza la necessità di interagire con il Server di Autenticazione (Per ulteriori dettagli sulla decodifica e validazione dei JWT, puoi fare riferimento alla documentazione di Logto).

Limitazioni del JWT

Sebbene i JWT offrano vantaggi significativi nelle architetture software moderne, presentano anche limitazioni da considerare.

Payload facilmente intercettato

Come menzionato in precedenza, un JWT è composto da tre parti: l'header, il payload e la signature. Come vengono generati questi componenti? Prendiamo il JWT dall'esempio precedente e dimostriamo il processo di generazione del JWT:

Come mostrato nel codice sopra, l'header e il payload del JWT sono semplicemente codificati come stringhe base64.

Ciò significa che finché qualcuno ha accesso al token, può facilmente decodificare la stringa base64 del payload del JWT e accedere alle informazioni che trasporta. Al contrario, è anche relativamente facile creare un payload e sostituire il payload originale del JWT con uno manipolato.

Sebbene sia vero che il payload di un JWT possa essere relativamente facilmente creato, è importante notare che la parte di firma del JWT non può essere sostituita con contenuti creati, poiché richiede la chiave di firma segreta. Pertanto, senza la corretta firma, il JWT non può superare la validazione.

Quindi, quando si utilizzano i JWT, è importante tenere a mente le seguenti considerazioni:

Utilizzare sempre SSL: per garantire che le informazioni del JWT non vengano trapelate durante la trasmissione, è essenziale utilizzare SSL (Secure Sockets Layer) o il suo successore, TLS (Transport Layer Security), per crittografare i dati in transito.
Evitare di memorizzare dati sensibili: non è consigliabile memorizzare dati sensibili nel payload del JWT. Come accennato in precedenza, il payload può essere facilmente decodificato e dovrebbe contenere principalmente affermazioni non sensibili e rilevanti.
Validare i JWT: prima di fare affidamento sulle informazioni contenute in un JWT, assicurarsi che abbia superato un processo di validazione valido e sicuro, inclusa la verifica della firma e il controllo della scadenza del token. Questo aiuta a prevenire l'uso di token manomessi o non autorizzati.

Difficile da revocare

In generale, i token di accesso di solito hanno un tempo di scadenza. Se il token di accesso è rappresentato come stringhe casuali senza alcuna informazione, possiamo verificare se il token è stato revocato durante ciascuna validazione nel Server di Autenticazione.

Per quanto riguarda i JWT, a causa del fatto che i JWT contengono informazioni di scadenza all'interno di se stessi, e del fatto che la validazione dei JWT non dipende dal Server di Autenticazione, una volta che un Server di Autenticazione emette un token di accesso in formato JWT, diventa impossibile cambiare lo stato del token durante il suo utilizzo.

Dopo che un token JWT scade naturalmente, possiamo ottenere un nuovo JWT dal server di autorizzazione utilizzando un token di aggiornamento (puoi fare riferimento al blog di Logto per informazioni sui token di aggiornamento).

Tuttavia, in alcune situazioni, come quando un utente revoca l'autorizzazione o cambia la sua password, e hai bisogno di revocare un token già emesso ma non ancora scaduto, non esiste una soluzione diretta disponibile.

Ci sono due approcci comuni per mitigare l'impatto della revoca del token a metà:

Impostare un tempo di scadenza più breve per il token di accesso e affidarsi al meccanismo di aggiornamento del token per aggiornare prontamente lo stato del token.

Poiché il token di accesso ha un tempo di scadenza più breve, quando un utente scopre che il token di accesso è scaduto, può richiedere un nuovo token di accesso con un token di aggiornamento dal servizio di autorizzazione. In questo modo, lo stato del token sul lato dell'utente può sincronizzarsi con il backend il prima possibile. Tuttavia, questo approccio comporta un sovraccarico aggiuntivo, che gli utenti devono considerare.

Mantenere una lista di revoca per i token di accesso e verificare se il token è nella lista durante ciascuna validazione.

Questo metodo ha alcune limitazioni. Uno dei vantaggi del JWT è che non richiede al server di memorizzare informazioni di stato e i JWT sono tipicamente stateless. Tuttavia, mantenere una lista di revoca richiede un'efficace memorizzazione e manutenzione, affidandosi a meccanismi di archiviazione aggiuntivi. Questo essenzialmente sacrifica i vantaggi del JWT e può potenzialmente portare a problemi di prestazioni. Pertanto, il meccanismo di revoca del token deve essere implementato dagli sviluppatori in un modo adatto al loro caso d'uso specifico.

Riepilogo

In questo articolo, abbiamo fornito una breve introduzione a JWT, evidenziandone i vantaggi e le limitazioni. A questo punto, dovresti avere una comprensione più profonda di JWT e degli scenari in cui è comunemente usato. Sebbene il JWT presenti delle sfide, i vantaggi che porta quando viene utilizzato come formato del token nei servizi OAuth 2.0 superano di gran lunga i suoi svantaggi.

Logto, come servizio di autenticazione dell'identità in rapida crescita, impiega anche JWT come formato per i suoi token di accesso. Aderisce rigorosamente a vari protocolli di autorizzazione e autenticazione, rendendo eccezionalmente facile integrare i servizi di autenticazione dell'identità nei tuoi prodotti. Logto ha lanciato ufficialmente il suo servizio SaaS e puoi provarlo gratuitamente oggi.

Prova Logto Oggi

Introduzione a JWT#

Vantaggi dell'uso di JWT#

Limitazioni del JWT#

Payload facilmente intercettato#

Difficile da revocare#

Riepilogo#

Introduzione a JWT#

Vantaggi dell'uso di JWT#

Limitazioni del JWT#

Payload facilmente intercettato#

Difficile da revocare#

Riepilogo#

Introduzione a JWT

Vantaggi dell'uso di JWT

Limitazioni del JWT

Payload facilmente intercettato

Difficile da revocare

Riepilogo

Introduzione a JWT

Vantaggi dell'uso di JWT

Limitazioni del JWT

Payload facilmente intercettato

Difficile da revocare

Riepilogo