Un token JWT, acronimo di JSON Web Token, è un formato compatto per passare claims tra due parti. Le applicazioni utilizzano comunemente i JWT dopo il login: un server emette un token, il client lo invia con le richieste successive e un'API verifica il token prima di consentire l'accesso. Un JWT non è un token di criptovaluta e i suoi contenuti non sono automaticamente segreti.
I sistemi di account in finanza, exchange e servizi Web3 possono utilizzare l'autenticazione basata su token dietro le quinte. I lettori che esplorano le piattaforme di asset digitali possono creare un account Tapbit, mentre gli sviluppatori dovrebbero trattare ogni token di autenticazione come una credenziale sensibile alla sicurezza.
Cos'è un token JWT?
Lo standard JWT, RFC 7519, definisce un formato compatto di claims progettato per la trasmissione come oggetto JSON. Un claim è un'affermazione come un identificatore utente, l'emittente del token, il destinatario previsto o il tempo di scadenza. I JWT sono spesso utilizzati come token di accesso, token di identità o messaggi di breve durata tra servizi.
Spesso si dice "token JWT", anche se la "T" finale significa già token. La ripetizione è comune e innocua. Ciò che conta è capire che JWT descrive un formato, non un sistema di login completo. L'autenticazione sicura richiede anche politiche corrette di emissione, validazione, archiviazione, scadenza e revoca.
Come funziona un JSON Web Token?
Un tipico flusso di login inizia quando un utente invia credenziali valide. Il server di autenticazione crea un JWT contenente claims selezionati e lo protegge con una firma digitale o un codice di autenticazione del messaggio. Il client presenta quindi il JWT a un'API, spesso in un header di autorizzazione HTTP utilizzando lo schema Bearer.
L'API verifica la firma e controlla i claims richiesti prima di fidarsi della richiesta. Controlli importanti possono includere l'emittente, il destinatario, il tempo di scadenza e l'algoritmo previsto dall'applicazione. Se la verifica ha successo, l'API utilizza i claims per prendere una decisione di autorizzazione. Se fallisce, la richiesta dovrebbe essere rifiutata.
Le tre parti di un JWT
Un JWT firmato comunemente visto ha tre sezioni codificate in Base64url separate da punti:
header.payload.signature
- Header: identifica il tipo di token e l'algoritmo di firma.
- Payload: contiene i claims, come
subper soggetto,issper emittente,audper destinatario eexpper scadenza. - Signature: consente al destinatario di rilevare modifiche non autorizzate e verificare il firmatario quando viene utilizzata la chiave corretta.
La codifica Base64url non è crittografia. Chiunque ottenga un normale JWT firmato può solitamente decodificare il suo header e payload. Le informazioni sensibili non dovrebbero quindi essere inserite nel payload a meno che il sistema non utilizzi un formato crittografato appropriato e abbia una chiara necessità.
Esempio JWT per principianti
Considera un'API che emette un token dopo che Alice ha effettuato l'accesso. Il suo payload potrebbe identificare Alice come soggetto, nominare l'emittente, specificare il destinatario dell'API e scadere in 15 minuti. Quando Alice richiede il suo profilo, l'API convalida il token e utilizza il claim del soggetto per localizzare l'account corretto.
Se qualcuno modifica il payload dall'identificatore di Alice a quello di un amministratore, la firma non corrisponderà più. Questo è il vantaggio principale di un JWT firmato: la manomissione diventa rilevabile. Una firma valida, tuttavia, non prova che ogni claim sia appropriato. L'API deve comunque confermare che il token provenga dall'emittente previsto e fosse destinato a quell'API.
JWT vs Session Cookies vs API Keys
| Metodo | Scopo tipico | Dove risiede lo stato | Considerazione principale |
|---|---|---|---|
| JWT | Claims e autorizzazione API | Il token trasporta i claims; i server potrebbero comunque mantenere lo stato | Progettazione di validazione e revoca |
| Session cookie | Sessione di login del browser | Solitamente store di sessione lato server | Protezioni cookie e CSRF |
| API key | Identificare un'applicazione o un progetto | Il server mappa la chiave ai permessi | Le chiavi sono segreti a lunga durata a meno che non vengano ruotate |
I JWT non sono automaticamente migliori delle sessioni. Le sessioni possono rendere la revoca immediata semplice, mentre i JWT possono ridurre i lookup ripetuti nel database e funzionare bene tra servizi distribuiti. Molti sistemi combinano entrambi gli approcci, come un JWT di breve durata con un record di refresh-token gestito dal server.
I JWT sono crittografati?
Di solito no. Il familiare JWT a tre parti è comunemente un oggetto JSON Web Signature firmato. La firma fornisce integrità e autenticità se implementata correttamente, ma non nasconde il payload. JSON Web Encryption è uno standard correlato che può fornire riservatezza, sebbene utilizzi una struttura diversa e aggiunga complessità nella gestione delle chiavi.
Questa distinzione è importante perché gli sviluppatori a volte incollano un JWT in un decoder e rimangono sorpresi nel vedere dati leggibili. La decodifica non equivale a verificare con successo la firma. Le applicazioni non dovrebbero mai concedere l'accesso basandosi solo sui claims decodificati.
Rischi comuni di sicurezza JWT
Le Best Current Practices per JWT, RFC 8725, dell'IETF affrontano i fallimenti di implementazione che sono apparsi nei sistemi reali. I problemi più grandi di solito derivano da una validazione errata piuttosto che dal formato di base stesso.
- Confusione sull'algoritmo: accettare un algoritmo inatteso o insicuro.
- Mancanza di controlli sui claims: ignorare emittente, destinatario, scadenza o altri requisiti dell'applicazione.
- Furto di token: esporre un token bearer tramite log, script, archiviazione insicura o trasporto non protetto.
- Chiavi deboli: utilizzare segreti indovinabili o non riuscire a ruotare le chiavi di firma compromesse.
- Scadenza lunga: lasciare che i token rubati siano utili troppo a lungo.
- Revoca scarsa: presumere che un token firmato non possa mai necessitare di invalidazione anticipata.
Best Practice JWT
Le applicazioni dovrebbero consentire esplicitamente solo gli algoritmi che supportano, verificare ogni claim richiesto e utilizzare regole di validazione separate per diversi tipi di JWT. I token dovrebbero essere di breve durata, trasmessi solo tramite HTTPS ed esclusi da URL e log di routine. Le chiavi di firma necessitano di archiviazione sicura, rotazione e proprietà chiara.
L'archiviazione dipende dall'applicazione. I sistemi browser possono utilizzare cookie sicuri, HttpOnly e SameSite, mentre i client mobili o backend utilizzano archiviazione protetta appropriata alla piattaforma. Nessuna scelta di archiviazione elimina ogni minaccia, quindi gli sviluppatori devono considerare insieme cross-site scripting, cross-site request forgery, replay di token e compromissione del dispositivo.
Conclusione
Un JWT è un modo compatto per trasportare claims verificabili tra sistemi. Il suo header descrive come è protetto, il suo payload contiene i claims e la sua firma aiuta i destinatari a rilevare manomissioni. I JWT possono semplificare l'autenticazione API, ma solo quando il destinatario verifica l'algoritmo corretto, l'emittente, il destinatario, i claims temporali e la firma. Per i principianti, la regola chiave è semplice: un JWT è un formato di credenziale, non la prova che un intero design di autenticazione sia sicuro.
Domande frequenti
Cosa significa JWT?
JWT sta per JSON Web Token, un formato compatto standardizzato per la trasmissione di claims come JSON.
Chiunque può decodificare un JWT?
Chiunque abbia un tipico JWT firmato può solitamente decodificare il suo header e payload. La decodifica non verifica la firma né rende i claims affidabili.
Un JWT è uguale a un access token?
No. Un access token descrive uno scopo, mentre JWT descrive un formato. Alcuni access token sono JWT, altri sono stringhe opache.
Quanto dovrebbe durare un JWT?
Non esiste una durata universale. Gli access token sono comunemente di breve durata, con la durata esatta basata sui requisiti di rischio, revoca e usabilità del sistema.
Un JWT può essere revocato?
Sì, ma la revoca richiede una progettazione aggiuntiva, come una denylist, la rotazione delle chiavi, il versioning dei token o un sistema di refresh-token gestito dal server.
