Best practice per un'implementazione sicura di JWT

I JWT sono sicuri solo quanto la loro implementazione. La specifica è flessibile; la flessibilità crea vulnerabilità. Seguire queste best practice per evitare le insidie comuni che hanno causato elusioni dell'autenticazione nei sistemi di produzione.

Specificare sempre esplicitamente l'algoritmo previsto: jwt.decode(token, key, algorithms=["RS256"]). Non leggere mai l'algoritmo dall'header del token per selezionare la chiave di verifica o il percorso di codice. Questo previene gli attacchi alg=none e di confusione delle chiavi.

Token di accesso: 15-60 minuti. Refresh token: 7-30 giorni, archiviati in cookie httpOnly (non in localStorage). Alla scadenza, il client usa il refresh token per ottenere un nuovo token di accesso dal server di autenticazione senza richiedere una nuova autenticazione.

Validare aud (audience) per assicurarsi che il token sia stato emesso per il proprio servizio e non per un altro. Validare iss (issuer) rispetto all'URL del proprio server di autenticazione. Senza questi controlli, un token di un'altra app firmato con la stessa chiave verrebbe accettato.

Token di accesso in memoria (variabile JS) — vengono cancellati alla chiusura della scheda. Refresh token in cookie httpOnly, Secure, SameSite=Strict — inaccessibili a JavaScript. Non archiviare mai i JWT in localStorage: XSS può sottrarli.

I JWT sono stateless: non esiste una revoca integrata. Opzioni: mantenere una lista di revoca (denylist) verificata a ogni richiesta; usare una scadenza molto breve; usare token opachi con una ricerca centralizzata per i contesti ad alta sicurezza.

Ruotare regolarmente le chiavi di firma. Pubblicare più chiavi in JWKS con diversi valori di kid. Durante la rotazione: emettere nuovi token con il nuovo kid, mantenere attiva la vecchia chiave finché i vecchi token non scadono, quindi rimuovere la vecchia chiave da JWKS.

Non inserire mai dati sensibili (password, numeri di previdenza sociale, carte di credito) nel payload JWT: è codificato in base64url, non crittografato. Usare JWE (JSON Web Encryption) se servono claim crittografati, oppure conservare i dati sensibili sul server.

Trasmettere i JWT solo tramite HTTPS. Un JWT intercettato su HTTP consente di eludere completamente l'autenticazione. Impostare il flag Secure sui cookie. Usare HSTS per impedire il downgrade del protocollo. Non registrare mai stringhe JWT complete nei log del server.

Usare librerie mantenute attivamente: PyJWT 2+, python-jose, auth0/node-jsonwebtoken 9+, Nimbus JOSE + JWT (Java). Evitare di implementare la verifica JWT da zero. Controllare regolarmente i database CVE per individuare vulnerabilità nelle librerie.

Testare tutti i vettori d'attacco: inviare un token alg=none, un token di confusione RS256→HS256, un token scaduto, un token con audience errata e un payload manomesso. Usare jwt.io per creare token di test. Aggiungere test di integrazione che verifichino il rifiuto di questi token con 401.

Usare i JWT in modo sicuro richiede algoritmi vincolati, una breve scadenza dei token di accesso, l'archiviazione dei refresh token in cookie httpOnly, la validazione di audience e issuer e la rotazione delle chiavi. Prossimo argomento: schemi crittografici di condivisione dei segreti.