JWT vs Autenticazione basata su sessione

In generale, il primo passo per utilizzare un'applicazione è l'autenticazione, dove l'utente finale fornisce le proprie credenziali d'identità per accedere con successo. Dopo questo passaggio, il sistema d'identità (cioè il fornitore d'identità, server di autenticazione, ecc.) sa chi è l'utente e a quali risorse può accedere.

Dato che l'HTTP è intrinsecamente senza stato, ogni richiesta in una sessione è indipendente e non richiama informazioni dalle precedenti. Ri-autenticare gli utenti per ogni azione è fastidioso e danneggia l'esperienza utente.

Entriamo quindi nell'autenticazione basata su sessione e nell'autenticazione JWT (JSON Web Tokens), due metodi popolari per mantenere lo stato di autenticazione. Ognuno ha vantaggi unici e compromessi, e la scelta tra i due dipende dalle esigenze specifiche della tua applicazione. Se stai decidendo tra i due, questa guida è qui per aiutarti.

Cos'è l'autenticazione basata su sessione?#

L'autenticazione basata su sessione si basa sul server per mantenere un record dello stato d'autenticazione dell'utente. Creando e gestendo le sessioni, il server consente agli utenti di rimanere connessi e continuare a interagire con un'applicazione senza dover reinserire le credenziali a ogni richiesta.

Come funziona l'autenticazione basata su sessione?#

Creazione della sessione

1. Un utente si autentica e fornisce alcune credenziali (ad es. email e password).
2. Se le credenziali sono valide, il server crea un record persistente che rappresenta quella sessione. La sessione contiene informazioni come una stringa casuale, l'identificatore dell'utente, l'orario di inizio della sessione, l'orario di scadenza della sessione, ecc.
3. Il SessionID viene memorizzato nel database e restituito al client dell'utente come cookie.

Validazione della sessione

1. Il processo può essere avviato manualmente dall'utente (ad esempio, facendo clic su una scheda, aggiornando una pagina) o automaticamente dal client (ad esempio, durante i caricamenti iniziali della pagina o tramite chiamate API con un SessionID).
2. Ogni chiamata successiva invia una richiesta HTTP dal client contenente il cookie di sessione al server.
3. Il server valida il SessionID consultando i dati di sessione memorizzati sul server.
4. Se valido, il server elabora la richiesta e autorizza l'utente.

Come revocare una sessione?#

Le sessioni possono essere invalidate in tempo reale, il che è utile in situazioni in cui è necessario revocare rapidamente l'accesso.

• L'utente si disconnette manualmente: Il server elimina il record della sessione, effettuando il logout dell'utente.
• Gli amministratori forzano il logout dell'utente: Gli amministratori o i sistemi possono terminare una sessione specifica eliminandola dal database. Ad esempio, durante una violazione della sicurezza.
• Scadenza delle sessioni: Le sessioni possono scadere automaticamente dopo un periodo prestabilito di inattività, o un limite di tempo fisso.

Vantaggi dell'autenticazione basata su sessione#

• Semplice e affidabile: Il record della sessione fornisce una fonte chiara e centralizzata, consentendo un alto grado di fiducia e rendendo più affidabili le decisioni di autorizzazione.
• Revoca in tempo reale: Eliminando o invalidando il record della sessione, l'accesso di un utente può essere rapidamente revocato.

Svantaggi dell'autenticazione basata su sessione#

• Latenza nei sistemi distribuiti: Mantenere i dati di sessione su più server richiede sempre la sincronizzazione di uno store di sessione. Questo introduce latenza aggiuntiva perché il server deve controllare lo store di sessione ogni volta che viene effettuata una richiesta.
• Alto consumo di risorse: Ogni sessione consuma risorse del server, influenzando le prestazioni quando la base utenti cresce.
• Rischio di sicurezza: Il dirottamento di sessioni (tramite cookie di sessione rubati) può consentire l'accesso non autorizzato agli account utente.
• Uso limitato per API: L'autenticazione basata su sessione non è ideale per le app mobili. Memorizza i dati delle sessioni sul server, il che può aumentare il carico e la complessità con molti utenti. Inoltre, utilizza i cookie, che sono più difficili da gestire sui dispositivi mobili.

Cos'è l'autenticazione JWT?#

I JSON Web Tokens (JWT) adottano un approccio diverso incorporando tutte le informazioni rilevanti dell'utente direttamente in un token, usando un oggetto JSON. A differenza dei metodi basati su sessione, i JWT sono senza stato, il che significa che il server non gestisce record di autenticazione.

Come funziona l'autenticazione JWT?#

Un JWT è costituito da tre parti: una header, payload e una signature.

• L'header contiene l'algoritmo di firma (ad es., HS256) e il tipo di token (JWT).
• Il payload contiene affermazioni centrali come l'identità dell'utente, il ruolo dell'utente e il tempo di scadenza.
• La signature utilizza una chiave per firmare l'header e il payload, consentendo la verifica se la firma è stata manomessa.

Emissione JWT

1. Il client invia le credenziali utente al server di autenticazione (un fornitore universale di identità è particolarmente utile per gestire l'accesso tra più domini).
2. Al successo dell'autenticazione, il server genera un JWT che include header, payload e firma.
3. AuthServer invia il token emesso al Client. Il client memorizza il JWT (ad es. nei cookie, localStorage o sessionStorage).

I flussi basati su sessione seguono un processo simile. Tuttavia, dopo l'autenticazione, le informazioni dell'utente sono memorizzate sul server all'interno di una sessione, mentre i JWT si affidano ai token inviati al client per la memorizzazione e l'uso successivo.

Validazione del token

1. Per le richieste API successive, il client invia il JWT nell'header Authorization (Bearer <token>).
2. Il server verifica la firma del JWT usando una chiave segreta o pubblica e controlla le sue affermazioni (ad es., scadenza, emittente).
3. Se il token è valido, il server concede al client l'accesso alle risorse richieste.

L'autenticazione basata su sessione richiede al server di interrogare uno store di sessione, che può essere lento, specialmente se si basa su database esterni o centralizzati. Al contrario, l'autenticazione JWT è senza stato, con tutte le informazioni necessarie memorizzate nel token client, e utilizzando la firma per garantire la sicurezza. Questo elimina la necessità della gestione della sessione, rendendola più veloce e scalabile, specialmente nei sistemi distribuiti.

Come revocare un JWT?#

Dal lato client, disconnettersi di solito significa cancellare la sessione locale e rimuovere i token (ID, accesso, refresh token) dallo storage. Tuttavia, per l'autenticazione JWT, ciò avviene solo localmente, lasciando intatta la sessione centralizzata sul server di autorizzazione. Di conseguenza, gli utenti potrebbero ancora accedere ad altre app sotto la stessa sessione fino a quando il token non scade o non viene terminato manualmente.

Revocare un JWT (JSON Web Token) è più difficile rispetto all'autenticazione basata su sessione perché i JWT sono senza stato e non possono essere invalidati una volta emessi, a meno che non vengano implementate strategie specifiche. I metodi comuni includono:

• Brevi tempi di scadenza: Imposta un'affermazione exp breve (ad es., 15 minuti) per il JWT. Una volta scaduto, l'utente deve ri-autenticarsi. Questo minimizza il rischio se un token viene compromesso, poiché l'attaccante può usarlo solo per un tempo limitato. Per mantenere un'esperienza utente fluida, si possono utilizzare i token di aggiornamento per minimizzare l'inconveniente di ri-autenticazione.
• Blacklist del token: Per i casi critici (ad es., logout dell'utente, cambi di password), mantieni una blacklist di token revocati. Il server controlla i token in arrivo rispetto a questa lista nera e respinge eventuali corrispondenze. Sebbene efficace, questo approccio richiede di tenere traccia dei token revocati, il che va contro la natura senza stato dei JWT e può diventare inefficiente se la lista diventa troppo grande.
• Endpoint di revoca: Introduci un endpoint di revoca sul server di autorizzazione dove i token (ad es., i token di aggiornamento) possono essere invalidati. Una volta che un token di aggiornamento è revocato, tutti i token di accesso emessi da esso non verranno più rinnovati. Questo metodo funziona bene nei flussi di OAuth2.

Vantaggi dell'autenticazione JWT#

• Veloce e più informativo: La natura auto-contenuta dei JWT rende la verifica lato client più veloce e più efficiente, senza la necessità di interazione con il server. Possono anche includere affermazioni personalizzate (ad es., ruoli utente o altri dati rilevanti) all'interno del token, consentendo ai server di determinare i ruoli senza interrogare un database.
• Sicurezza migliorata: I JWT utilizzano tecniche di firma e crittografia, rendendo gli attacchi più difficili.
• Supporto multi-dominio: I JWT sono perfetti per il Single Sign-On (SSO) e l'autenticazione cross-domain. Consentono agli utenti di autenticarsi tra più domini o servizi con lo stesso token.
• Compatibile con dispositivi mobili: I JWT funzionano bene per le applicazioni mobili che necessitano di autenticazione senza stato. I token possono essere memorizzati sul lato client e inviati con ogni richiesta, migliorando l'efficienza e la facilità d'uso.

Svantaggi dell'autenticazione JWT#

• Il JWT non si aggiorna in tempo reale

  Una volta firmato un JWT, non può essere revocato o aggiornato, e sarà considerato valido fintanto che la firma è valida e non è scaduta.

  Se le autorizzazioni di accesso di un utente cambiano (solitamente vengono degradate), l'utente avrà comunque rimosso l'accesso alle risorse fino alla scadenza del JWT. Allo stesso modo, se un JWT contiene informazioni di autorizzazione basate sui ruoli, il nuovo ambito di autorizzazione non avrà effetto finché il vecchio JWT non scadrà. In altre parole, i JWT non sono adatti per la revoca in tempo reale e gli utenti possono impostare un tempo di scadenza adeguato per mitigare questo problema.

• Dilemma della revoca e dei dispositivi multipli

  Non è possibile convalidare tutti i JWT emessi prima che scadano per implementare la revoca utente su tutti i dispositivi. Sebbene teoricamente sia possibile revocare la chiave di firma per rendere il JWT non valido, ciò invaliderebbe anche tutti i JWT che utilizzano quella chiave e il processo di gestione delle chiavi cache renderebbe questo approccio impraticabile per semplici operazioni di revoca utente.

Alcuni fornitori d'identità potrebbero avere soluzioni pre-costruite per questi problemi con i JWT. Per ulteriori informazioni, consulta "Best Practices to Enhance the JWT Authentication Experience."

Qual è la differenza tra JWT e Sessione?#

Le sessioni e i JWT sono due approcci popolari per mantenere il contesto di autenticazione e autorizzazione in un mondo HTTP senza stato. Mentre entrambi gli approcci hanno i loro pro e contro, offrono diversi benefici e svantaggi.

Le sessioni, forniscono garanzie più forti per l'autorizzazione delle singole richieste e sono più semplici da implementare in modo sicuro. Tuttavia, la loro dipendenza dalla validazione del database lato server introduce un sovraccarico di latenza, che può influire negativamente sull'esperienza dell'utente per le applicazioni altamente reattive.

I JWT, d'altra parte, sono vantaggiosi per l'autorizzazione più veloce e l'interoperabilità con app esterne, ma richiedono più impegno da parte degli sviluppatori per affrontare le complessità di sicurezza. Ad esempio, possiamo utilizzare webhook per notificare ai clienti quando l'accesso dell'utente viene revocato, in modo che i clienti possano cancellare il JWT memorizzato nella cache e costringere l'utente a riallineare.

Poiché l'autenticazione basata su token è più adatta per l'espansione con i suoi svantaggi ancora gestibili, viene adottata da più e più applicazioni moderne.

Sessione vs. JWT: Scegliere il metodo giusto#

Il tuo metodo di autenticazione dovrebbe corrispondere all'architettura e alle esigenze specifiche della tua app. Ecco una breve guida per aiutarti a decidere:

Quando usare l'autenticazione basata su sessione#

L'autenticazione basata su sessione è più adatta quando hai bisogno di un controllo in tempo reale della sessione, di una gestione centralizzata o quando la scalabilità non è una preoccupazione principale. Ecco dove eccelle:

• Applicazioni web con sessioni persistenti

  Per piattaforme come i siti di acquisti online, le sessioni sono essenziali per tracciare gli utenti, i carrelli e le preferenze durante la loro visita.

• Applicazioni che richiedono un controllo in tempo reale della sessione

  Applicazioni come i servizi bancari o finanziari beneficiano di dati di sessione controllati dal server, garantendo una gestione e una sicurezza degli accessi robuste.

• Sistemi a server singolo o di piccola scala

  Strumenti interni o app di piccola scala senza necessità di scalabilità pesante prosperano su una semplice gestione delle sessioni per facilità d'uso e affidabilità.

Quando usare l'autenticazione JWT#

L'autenticazione JWT è più adatta per applicazioni che danno priorità alla scalabilità, all'efficienza e ai sistemi distribuiti. È particolarmente utile per interazioni senza stato tra clienti e server. Considera l'autenticazione basata su token per i seguenti casi:

• Single Sign-On (SSO)

  I JWT sono perfetti per il Single Sign-On, consentendo agli utenti di autenticarsi una volta e accedere senza problemi a più servizi o applicazioni utilizzando lo stesso token. Condividi una spiegazione dettagliata su applicazioni cloud sicure utilizzando OAuth 2.0 e OIDC, con formato JWT per entrambi i token di accesso e i token ID.

• Applicazioni mobili

  Le app mobili spesso preferiscono i JWT per l'autenticazione poiché i token possono essere memorizzati in modo sicuro sul dispositivo e inviati con ogni richiesta API. Esplora l'integrazione rapida dell'autenticazione JWT per Android / iOS.

• Architetture a microservizi

  Negli ambienti a microservizi, i JWT consentono a ciascun servizio di convalidare autonomamente il token senza fare affidamento su un archivio di sessioni centrale, garantendo scalabilità ed efficienza.

• Autenticazione multi-dominio

  I JWT eccellono negli scenari che coinvolgono più domini o sottodomini (ad esempio, api.example.com, dashboard.example.com, e docs.example.com). A differenza dei cookie, i JWT consentono l'autenticazione tra domini senza dipendenze aggiuntive.

• API e servizi web

  Le API RESTful e i servizi web utilizzano comunemente i JWT per l'autenticazione perché sono leggeri, portabili e eliminano la necessità di un centro di gestione delle sessioni sul server. Scopri di più sull'autenticazione macchina-a-macchina per gli scenari in cui la tua app deve comunicare direttamente con risorse.

Migliori pratiche per migliorare l'esperienza di autenticazione JWT#

L'autenticazione JWT è un ottimo strumento, ma può comportare sfide che influenzano l'esperienza dell'utente. Logto offre una soluzione semplice e affidabile per superare questi ostacoli, rendendolo una scelta top per un'autenticazione sicura ed efficiente.

Gestire i problemi di disconnessione degli utenti con JWT#

Un problema comune con l'autenticazione JWT è garantire una corretta esperienza di disconnessione degli utenti. Logto semplifica questo processo con il suo SDK out-of-the-box.

• Cancellando i token e le sessioni locali sul lato client e reindirizzando gli utenti all'endpoint di fine sessione di Logto, puoi terminare facilmente le sessioni sia sull'applicazione client che sul server.
• Inoltre, Logto supporta il logout back-channel, consentendo all'AuthServer di notificare a tutte le applicazioni client che condividono la stessa sessione quando un utente si disconnette.

Questo assicura una gestione coerente e sicura delle sessioni nel tuo ecosistema. Scopri di più sui meccanismi di disconnessione e su come implementare la disconnessione.

Gestire i cambiamenti delle autorizzazioni utente#

Gestire i cambiamenti in tempo reale delle autorizzazioni degli utenti con JWT può anche essere complicato. Poiché i JWT sono progettati per essere senza stato, eventuali autorizzazioni aggiornate o ruoli potrebbero non avere effetto fino alla scadenza del token. Logto offre strategie per gestire questo in modo efficace:

• Per ridurre le autorizzazioni per questo utente: Utilizza tempi di scadenza del token di accesso brevi o verifica dinamicamente le autorizzazioni tramite una chiamata API.
• Per aggiungere nuove autorizzazioni per questo utente: Aggiorna l'AuthServer per includere il nuovo ambito di autorizzazione e ri-consenti agli utenti di applicare queste modifiche.

Queste soluzioni aiutano a mantenere aggiornate le autorizzazioni e a garantire un sistema più sicuro e reattivo. Scopri di più su come gestire i cambiamenti in tempo reale delle autorizzazioni degli utenti.

Logto, che è un'infrastruttura scalabile di gestione degli accessi identitari, fornisce una soluzione completa di identità con entrambi servizi cloud e versione open-source disponibili.