JWT vs Autenticazione a sessione

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

Dato che HTTP è intrinsecamente senza stato, ogni richiesta in una sessione è indipendente e non ricorda le informazioni delle precedenti. Riautenticare gli utenti per ogni azione è scomodo 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 e compromessi unici, 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 affida al server per mantenere un record dello stato di autenticazione dell'utente. Creando e gestendo sessioni, il server consente agli utenti di rimanere collegati e continuare a interagire con un'applicazione senza dover inserire nuovamente 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, identificatore utente, ora di inizio della sessione, ora di scadenza della sessione, ecc.
3. Il SessionID viene memorizzato nel database e restituito al client dell'utente come un cookie.

Validazione della sessione

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

Come revocare una sessione?#

Le sessioni possono essere invalidate in tempo reale, il che è utile in situazioni dove è necessaria una revoca rapida dell'accesso.

• Logout manuale degli utenti: Il server elimina il record della sessione, disconnettendo efficacemente l'utente.
• Logout forzato dagli amministratori: Gli amministratori o i sistemi possono terminare sessioni specifiche eliminandole dal database. Ad esempio, durante una violazione di sicurezza.
• Scadenza delle sessioni: Le sessioni possono scadere automaticamente dopo un certo periodo di inattività, o un limite di tempo fisso.

Vantaggi dell'autenticazione basata su sessione#

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

Svantaggi dell'autenticazione basata su sessione#

• Latenza nei sistemi distribuiti: Mantenere i dati della sessione su più server richiede sempre la sincronizzazione di uno store delle sessioni. Questo introduce una latenza aggiuntiva poiché il server deve controllare lo store delle sessioni ogni volta che viene effettuata una richiesta.
• Alto consumo di risorse: Ogni sessione occupa risorse del server, influenzando le prestazioni quando la base di utenti cresce.
• Rischio di sicurezza: L'hijacking delle sessioni (tramite cookie di sessione rubati) può consentire accessi non autorizzati agli account utente.
• Utilizzo limitato per le API: L'autenticazione basata su sessione non è ottima per le app mobili. Memorizza i dati della sessione sul server, il che può aumentare il carico e la complessità con molti utenti. Inoltre, utilizza i cookie, 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 sugli utenti direttamente in un token, utilizzando un oggetto JSON. A differenza dei metodi basati su sessione, i JWT sono senza stato, significando che il server non gestisce record di autenticazione.

Come funziona l'autenticazione JWT?#

Un JWT è composto da tre parti: un header, payload, e signature.

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

Emissione del JWT

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

I flussi basati su sessione seguono un processo simile. Tuttavia, dopo l'autenticazione, le informazioni utente vengono memorizzate sul server all'interno di una sessione, mentre i JWT si affidano a token inviati al client per essere memorizzati e utilizzati successivamente.

Validazione del token

1. Per le richieste API successive, il client invia il JWT nell'header Authorization (Bearer <token>).
2. Il server verifica la signature del JWT utilizzando una chiave segreta o pubblica e controlla le sue claims (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 delle sessioni, il che può essere lento, specialmente se si affida a database esterni o centralizzati. Al contrario, l'autenticazione JWT è senza stato, con tutte le informazioni necessarie memorizzate nel token del client, e utilizza la firma per garantire la sicurezza. Ciò elimina la necessità di una gestione delle sessioni, rendendola più veloce e scalabile, in particolare nei sistemi distribuiti.

Come revocare un JWT?#

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

Revocare un JWT (JSON Web Token) è più impegnativo 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 specifiche strategie. I metodi comuni includono:

• Tempi di scadenza brevi: Impostare una claim 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ò utilizzarlo solo per un tempo limitato. Per mantenere un'esperienza utente senza interruzioni, token di aggiornamento può essere usato per minimizzare l'inconveniente della ri-autenticazione.
• Blacklist dei token: Per casi critici (ad es., logout dell'utente, cambio password), mantenere una blacklist di token revocati. Il server controlla i token in arrivo contro questa lista e rifiuta qualsiasi corrispondenza. Anche se 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 cresce troppo.
• Endpoint di revoca: Introdurre un endpoint di revoca sul server di autorizzazione dove i token (ad es., token di aggiornamento) possono essere invalidati. Una volta che un token di aggiornamento è revocato, qualsiasi token di accesso emesso da esso non verrà più rinnovato. Questo metodo funziona bene nei flussi OAuth2.

Vantaggi dell'autenticazione JWT#

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

Svantaggi dell'autenticazione JWT#

• Il JWT non viene aggiornato in tempo reale

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

  Se cambiano i permessi di accesso di un utente (solitamente ridotti), l'utente avrà ancora accesso alle risorse rimosse fino alla scadenza del JWT. Allo stesso modo, se un JWT contiene informazioni di autorizzazione basate su ruolo, il nuovo scopo di autorizzazione non prenderà effetto fino alla scadenza del vecchio JWT. In altre parole, i JWT non sono adatti per revoche in tempo reale e gli utenti possono impostare un tempo di scadenza adeguato per mitigare questo problema.

• Dilemma su dispositivi multipli e revoche

  Non è possibile convalidare tutti i JWT emessi prima che scadano per implementare la revoca utente su tutti i dispositivi. Sebbene sia teoricamente possibile revocare la chiave di firma per rendere il JWT invalido, questo 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 di identità potrebbero avere soluzioni predefinite per questi problemi dei JWT. Per ulteriori informazioni, consulta le "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. Sebbene entrambi gli approcci abbiano i loro pro e contro, offrono benefici e svantaggi diversi.

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 convalida lato server tramite database introduce un sovraccarico di latenza, che può influire negativamente sull'esperienza utente per applicazioni altamente reattive.

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

Poiché l'autenticazione basata su token è più adatta a scalare con i propri svantaggi ancora gestibili, essa viene adottata da un numero sempre crescente di 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 guida rapida per aiutarti a decidere:

Quando usare l'autenticazione basata su sessione#

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

• Applicazioni web con sessioni persistenti

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

• Applicazioni che richiedono controllo della sessione in tempo reale

  Applicazioni come i servizi bancari o finanziari beneficiano dei dati delle sessioni controllati dal server, garantendo una gestione robusta dell'accesso e sicurezza.

• Sistemi single-server o di piccola scala

  Strumenti interni o app di piccola scala senza grandi esigenze di scalabilità prosperano sulla 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à a scalabilità, efficienza e sistemi distribuiti. È particolarmente utile per interazioni senza stato tra client e server. Considera l'autenticazione basata su token per i seguenti scenari:

• Single Sign-On (SSO)

  I JWT sono perfetti per il Single Sign-On, consentendo agli utenti di autenticarsi una volta e accedere senza soluzione di continuità 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 sia per i token di accesso che per i token ID.

• Applicazioni mobili

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

• Architetture microservizi

  Negli ambienti microservizi, i JWT consentono a ciascun servizio di convalidare autonomamente il token senza dipendere da uno store delle sessioni centrale, garantendo scalabilità ed efficienza.

• Autenticazione cross-domain

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

• API e servizi web

  Le API RESTful e i servizi web usano comunemente i JWT per l'autenticazione perché sono leggeri, portatili e eliminano la necessità di una gestione delle sessioni lato server. Scopri di più sull'autenticazione machine-to-machine per scenari in cui la tua app deve comunicare direttamente con le risorse.

Best practices per migliorare l'esperienza di autenticazione JWT#

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

Gestire i problemi di disconnessione dell'utente con JWT#

Un problema comune con l'autenticazione JWT è garantire un'esperienza di disconnessione utente adeguata. Logto semplifica questo processo con il suo SDK pronto all'uso.

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

Questo garantisce una gestione delle sessioni coerente e sicura in tutto il tuo ecosistema. Scopri di più su come gestire la disconnessione.

Gestire i cambiamenti di permessi dell'utente#

Gestire i cambiamenti in tempo reale dei permessi dell'utente con JWT può essere anche complicato. Poiché i JWT sono per design senza stato, qualsiasi permesso o ruolo aggiornato potrebbe non avere effetto finché il token non scade. Logto offre strategie per affrontare efficacemente questo:

• Per diminuire i permessi di questo utente: Usa tempi di scadenza brevi per il token di accesso o verifica dinamicamente i permessi tramite una chiamata API.
• Per aggiungere nuovi permessi a questo utente: Aggiorna il server di autenticazione per includere il nuovo scope di permesso e riconsenti agli utenti di applicare questi cambiamenti.

Queste soluzioni aiutano a mantenere i permessi aggiornati e garantiscono un sistema più sicuro e reattivo. Scopri di più su come gestire i cambiamenti di permessi.

Logto, che è un'infrastruttura di gestione degli accessi scalabile, fornisce una soluzione di identità completa sia con servizio cloud che versione open-source disponibile.