logo
GeekFormat

Decodificatore, Verificatore e Generatore JWT

Encoded Token172 charsAggiornato 2026-07
header
payload
signature
Valid JWTHS256
Secret38 chars
Header
{
  "alg": "HS256",
  "typ": "JWT"
}
Payload
{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1516239022
}
Claims details4 items
sub· Soggetto1234567890
name· NameJohn Doe
admin· Admintrue
iat· Emesso il151623902218/01/2018, 09:30:22
Header details2 items
algHS256HMAC (simmetrico)
typ· TypeJWT
All operations run locally in your browser; the Token and key are never sent to any server.

Banco di lavoro JWT online gratuito: decodifica, verifica e genera JSON Web Token. Supporta 13 algoritmi (HS256 / RS256 / ES256 / PS256 / EdDSA, ecc.). Chiavi PEM e JWK. Generazione automatica di coppie di chiavi. exp/iat/nbf analizzati automaticamente. 100% lato client — il token non lascia mai il tuo browser.

Raccomandazioni correlate

Casi d'uso

  • Decodificare JWT online: dividi rapidamente un token durante il debug dell'accesso OAuth 2.0 / OIDC per ispezionare l'algoritmo dell'Header e i Claims del Payload
  • Verificare le firme JWT: usa un Secret / chiave pubblica per convalidare le firme dei token in tempo reale e decidere se un 401 è 'firma errata', 'scaduto' o 'mancata corrispondenza dell'algoritmo'
  • Generare JWT di test durante l'integrazione: emetti un JWT nel browser con una coppia di chiavi di test, senza dover chiedere al backend di modificare temporaneamente il codice per emettere un token
  • Conversione PEM ↔ JWK: l'IdP OIDC ti ha dato JWK ma il server ha bisogno di PEM (o viceversa) — converti sul posto invece di scrivere uno script OpenSSL
  • Diagnosticare 401 Unauthorized: scorri la scadenza, la corrispondenza alg con il gateway, la corrispondenza delle chiavi e la formattazione PEM uno alla volta
  • Confrontare RS256 vs PS256: molti provider OIDC usano RS256 per impostazione predefinita mentre AWS SigV4 preferisce PS256 — cambia algoritmi con la stessa coppia di chiavi RSA e confronta i risultati
  • Imparare il funzionamento interno di JWT: cambia l'alg, modifica il Payload, scambia la chiave nel browser e guarda la firma rompersi in tempo reale — molto più veloce che leggere l'RFC

Funzionalità

  • Decodificare + Verificare + Generare in un unico posto: incolla un token per separare Header/Payload/Signature, cambia algoritmo e chiave per verificare la firma, modifica i Claims e firma di nuovo per produrre un nuovo token — copre l'intera catena di risoluzione dei problemi JWT
  • 13 algoritmi supportati: HS256/HS384/HS512 (HMAC), RS256/RS384/RS512 (RSA-PKCS1-v1_5), ES256/ES384/ES512 (ECDSA), PS256/PS384/PS512 (RSA-PSS), EdDSA — copre OAuth 2.0, OIDC, JWS, gateway API e SSO aziendale
  • Formati PEM e JWK: le chiavi RSA, ECDSA e Ed25519 accettano stringhe PEM (con intestazioni -----BEGIN PUBLIC KEY-----) e JSON JWK (campi kid/kty/n/e) — incolla direttamente l'output OIDC /.well-known/jwks.json
  • Molteplici forme di input per il Secret HMAC: stringa UTF-8 grezza, byte esadecimali o Secret codificato in Base64/Base64URL — cambia con un clic, così 'sembra uguale ma la firma fallisce' non accade mai
  • Generazione automatica di coppie di chiavi: coppie di chiavi RSA-2048, RSA-4096, P-256, P-384 e Ed25519 generate nel browser, presentate in formati PEM e JWK per uso immediato nei test
  • Evidenziazione semantica dei Claims: exp / iat / nbf vengono automaticamente convertiti in tempo leggibile dall'uomo con lo stato scaduto / non ancora valido / emesso evidenziato; alg / typ / kid nell'Header etichettati individualmente
  • 100% lato client, zero caricamenti: ogni analisi, verifica e firma viene eseguita tramite l'API Web Crypto nativa del browser — token, chiavi e payload non lasciano mai il browser, in linea con il principio di sicurezza di 'non incollare mai token di produzione in strumenti online sconosciuti'
  • Copia con un clic: Header, Payload, Signature e il token appena generato sono ciascuno copiabili indipendentemente per documentazione, ticket e comandi curl

Come utilizzare

  1. Incolla o digita il token: inserisci la stringa JWT nella casella di input; lo strumento separa automaticamente Header, Payload e Signature e visualizza ciascuno come JSON formattato
  2. Seleziona l'algoritmo: passa tra HS256 / RS256 / ES256 / PS256 / EdDSA; lo strumento deduce da Header.alg e segnala qualsiasi mancata corrispondenza
  3. Importa una chiave: incolla un Secret HMAC, una stringa PEM o un JSON JWK; per gli algoritmi asimmetrici, fai clic su 'Genera coppia di chiavi' per ottenere immediatamente una chiave di test
  4. Verifica o firma di nuovo: in modalità Decode verifica con una chiave pubblica e vedi '✅ firma valida / ❌ firma non valida'; in modalità Encode modifica i Claims e firma con una chiave privata per produrre un nuovo token

Domande frequenti

Quali sono le tre parti di un JWT?

Una stringa JWT è composta da tre segmenti `Header.Payload.Signature`, ciascuno codificato in Base64URL. L'Header dichiara l'algoritmo (ad esempio, HS256, RS256) e il tipo di token (typ: JWT); il Payload porta i Claims dell'utente, i campi comuni sono sub (ID utente), iat (ora di emissione), exp (ora di scadenza), nbf (non prima), aud (pubblico), iss (emittente); la Signature è il risultato della firma dei primi due segmenti con una chiave, il suo scopo è il 'rilevamento di manomissione' non la 'prevenzione dell'ascolto'.

Posso modificare il Payload dopo aver decodificato un JWT?

Puoi vederlo e modificarlo, ma **non puoi falsificarlo**. Una volta che cambi l'Header o il Payload, la Signature originale diventa immediatamente non valida e il server la rifiuterà. Affinché il token modificato torni a essere utilizzabile, devi **firmarlo di nuovo** con lo stesso algoritmo e la chiave corretta — questo è il motivo per cui questo strumento fornisce 'decodificare + modificare + generare' in un unico posto: decodifica per dare un'occhiata, modifica ciò che vuoi e genera un nuovo token per i test immediatamente, senza dover chiedere al backend di emettere temporaneamente.

Qual è la differenza tra HS256, RS256, ES256, PS256 e EdDSA?

HS256 usa HMAC con un Secret condiviso (simmetrico), veloce ma richiede una gestione sicura del Secret; RS256 usa chiavi RSA privata/pubblica (asimmetrico), adatto a situazioni in cui il firmatario e il verificatore sono separati; PS256 usa un padding RSA-PSS, più sicuro di RS256; ES256 usa una curva ellittica P-256, firme più corte e prestazioni migliori; EdDSA (normalmente Ed25519) è molto veloce e deterministico, raccomandato per nuovi protocolli come OAuth 2.1.

Perché il mio JWT mostra firma non valida?

Le cause più comuni sono che la chiave, il formato del Secret, l'algoritmo o la codifica Base64URL non corrispondono esattamente. Uno spazio aggiuntivo, un ritorno a capo PEM, confondere Base64 con Base64URL o che il server usi RS256 mentre lo strumento usa HS256 farà fallire la verifica. Usa questo strumento per cambiare algoritmi e formati di Secret e testare uno per uno.

La stessa chiave RSA può verificare RS256 e PS256?

No. RS256 e PS256 usano schemi di padding diversi (PKCS1-v1_5 vs PSS). Anche se la chiave RSA è la stessa, non possono verificarsi incrociatamente. Il firmatario e il verificatore devono usare lo stesso algoritmo.

Cos'è un attacco alg:none?

Un attaccante cambia l'Header in `{"alg":"none"}` per dire al server di non verificare la firma, o cambia RS256 in HS256 e usa la chiave pubblica come Secret HMAC per ingannare il server. Il server deve usare una whitelist di algoritmi (ad esempio, `algorithms: ['RS256']`) e non deve fidarsi del Header.alg del token per decidere l'algoritmo di verifica.

Come converto tra PEM e JWK?

PEM è il formato classico OpenSSL con righe BEGIN/END, comune nelle configurazioni ereditate; JWK è in formato JSON, comune in OAuth 2.0 / OIDC. Molti IdP OIDC pubblicano chiavi pubbliche su `/.well-known/jwks.json`. Questo strumento supporta entrambi i formati e può passare tra di essi.

Il browser può verificare direttamente le firme JWT?

Sì. L'API Web Crypto supporta HMAC, RSA, ECDSA, RSA-PSS e Ed25519 nei browser moderni, quindi questo strumento può verificare le firme direttamente nel browser senza caricare il token.

Il mio token viene inviato a un server?

No. L'analisi, la verifica e la firma vengono eseguite nel browser. Il pannello Network non dovrebbe mostrare alcuna richiesta contenente il token.

Posso memorizzare dati sensibili in un JWT?

No. Il Payload è leggibile per impostazione predefinita (basta decodificare Base64URL). Password, documenti di identità, numeri di carta, chiavi API, Access Token o Refresh Token non devono essere inseriti in un JWT standard. Se hai bisogno di riservatezza, considera JWE (JSON Web Encryption).

Cos'è il Decodificatore, Verificatore e Generatore JWT?

JWT (JSON Web Token) è uno standard aperto definito dall'IETF nella RFC 7519 (la RFC 7515 descrive la forma di firma JWS, la RFC 7516 descrive la crittografia JWE, la RFC 7517 definisce le chiavi JWK) per trasferire in modo sicuro informazioni utente 'asserite' tra richieste HTTP, flussi OIDC e chiamate di microservizi. Una stringa JWT standard è composta da tre segmenti codificati in Base64URL: Header (algoritmo e tipo), Payload (Claims, i dati utente) e Signature (una firma basata su chiave sui primi due). I tre segmenti sono uniti da un punto letterale `.`, ad esempio `eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c`.

**JWT non è crittografia.** Questo è l'equivoco più comune. Il Payload è in testo chiaro per impostazione predefinita — chiunque può decodificarlo con Base64URL e leggerne il contenuto. JWT fornisce **rilevamento di manomissione**, non riservatezza: il server firma di nuovo Header.Payload con la chiave condivisa e la confronta con la Signature del token. Se corrispondono, il token non è stato alterato in transito. Questa è la metafora del 'biglietto del treno con un timbro anti-contraffazione': all'ispettore importa se il biglietto è genuino, non se il codice QR è illeggibile.

JWT divide chiaramente le responsabilità tra 13 algoritmi. **Famiglia HMAC** (HS256/HS384/HS512) usa una chiave simmetrica sia per firmare che per verificare, veloce e semplice, adatta a un singolo servizio o a un cluster affidabile; il secret deve essere almeno lungo quanto il digest (ad esempio, ≥ 32 byte per HS256). **Famiglia RSA** (RS256/RS384/RS512) usa RSASSA-PKCS1-v1_5, lo schema asimmetrico più comune — i firmatari detengono la chiave privata, i verificatori detengono la chiave pubblica. **Famiglia RSA-PSS** (PS256/PS384/PS512) usa il padding RSA-PSS più recente con garanzie di sicurezza più forti, preferito da AWS SigV4 e dai provider di identità OIDC moderni. **Famiglia ECDSA** (ES256/ES384/ES512) usa curve ellittiche (P-256/P-384/P-521 rispettivamente) con firme più corte e prestazioni migliori. **EdDSA** (principalmente Ed25519) è estremamente veloce e deterministico (stesso messaggio + stessa chiave = stessa firma ogni volta) ed è l'algoritmo raccomandato in OAuth 2.1 e nei nuovi protocolli.

La sicurezza è dove JWT inciampa in produzione. La OWASP JWT Cheat Sheet evidenzia almeno quattro regole ferree: (1) non mettere mai password, documenti di identità, numeri di carta o chiavi API in testo chiaro nel Payload; (2) il server **non deve mai fidarsi del campo alg** dichiarato nell'Header del Token — deve verificare con un algoritmo codificato, altrimenti un attaccante che riscrive l'header a `alg: none` aggira tutto (questa è la radice di CVE storici come CVE-2015-9235); (3) i secret HMAC devono essere casuali e lunghi almeno 32 byte, mai stringhe corte; (4) la verifica è più che controllare le firme — devi anche convalidare `exp` (scadenza), `nbf` (non prima), `iss` (emittente) e `aud` (pubblico). Questo strumento evidenzia ciascuno di questi Claims nell'interfaccia utente per poter dire a colpo d'occhio se un fallimento è un problema di firma, un problema di temporizzazione o un problema di Claims.

JWT non è un sostituto delle sessioni. Le sessioni memorizzano lo stato dell'utente sul server (Redis o un database); JWT impacchetta lo stato nel token. Le architetture di microservizi, le API senza stato, i client mobili e le configurazioni con molto CORS traggono vantaggio da JWT; i sistemi aziendali tradizionali e i flussi che richiedono la revoca istantanea (ad esempio, 'espelli questo utente ora') sono ancora meglio serviti dalle sessioni. Questo strumento copre sia il debug JWT puro che i passaggi di analisi del Token / verifica della firma / modifica del Payload di una migrazione da sessione a JWT.

Code Examples

50 righe di Node.js: firma e verifica HS256 scritte a mano

javascript

Distilla il meccanismo centrale di JWT: codifica Header e Payload in Base64URL, poi applica HMAC-SHA256 alla stringa `header.payload`. In produzione, usa una libreria come jsonwebtoken o jose — questo frammento esiste per rendere i fallimenti di firma debuggabili.

const crypto = require('node:crypto')

function b64url(input) {
  return Buffer.from(input)
    .toString('base64')
    .replace(/\+/g, '-')
    .replace(/\//g, '_')
    .replace(/=+$/, '')
}

function hmacSign(data, secret) {
  return b64url(crypto.createHmac('sha256', secret).update(data).digest())
}

function sign(payload, secret) {
  const header = b64url(JSON.stringify({ alg: 'HS256', typ: 'JWT' }))
  const body = b64url(JSON.stringify(payload))
  const signature = hmacSign(`${header}.${body}`, secret)
  return `${header}.${body}.${signature}`
}

function verify(token, secret) {
  const [h, p, s] = token.split('.')
  const expected = hmacSign(`${h}.${p}`, secret)
  const a = Buffer.from(s)
  const b = Buffer.from(expected)
  return a.length === b.length && crypto.timingSafeEqual(a, b)
}

const SECRET = 'my-super-secret-key'
const payload = { userId: 42, role: 'admin', exp: Math.floor(Date.now() / 1000) + 3600 }
const token = sign(payload, SECRET)

console.log(token)
console.log(verify(token, SECRET))       // true
console.log(verify(token, 'wrong-key'))  // false

Lato browser: API Web Crypto per la firma HMAC

html

L'idea centrale del front-end di questo strumento: usa crypto.subtle nativo del browser per la verifica HMAC, RSA, ECDSA, RSA-PSS e Ed25519 — nessuna libreria di terze parti necessaria. Inserisci questo in qualsiasi pagina HTML per coniare token HS256.

<!doctype html>
<html>
  <body>
    <pre id="out"></pre>
    <script>
      const out = document.getElementById('out')

      const b64url = buf =>
        btoa(String.fromCharCode(...new Uint8Array(buf)))
          .replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')

      const b64urlStr = str => b64url(new TextEncoder().encode(str))

      async function sign(payload, secret) {
        const header = b64urlStr(JSON.stringify({ alg: 'HS256', typ: 'JWT' }))
        const body = b64urlStr(JSON.stringify(payload))
        const data = new TextEncoder().encode(`${header}.${body}`)

        const key = await crypto.subtle.importKey(
          'raw',
          new TextEncoder().encode(secret),
          { name: 'HMAC', hash: 'SHA-256' },
          false,
          ['sign']
        )

        const sig = await crypto.subtle.sign('HMAC', key, data)
        return `${header}.${body}.${b64url(sig)}`
      }

      ;(async () => {
        const token = await sign({ user: 'alice', role: 'admin' }, 'browser-demo-secret')
        out.textContent = token
      })()
    </script>
  </body>
</html>

Node.js: verifica RS256 con jose (il modo corretto)

javascript

Usa una libreria matura come jose, jsonwebtoken o PyJWT in produzione — non scrivere mai la tua. Questo frammento mostra come jose verifica un token RS256, stampa il motivo del fallimento in caso di errore (mancata corrispondenza di alg, firma errata, scaduto, kid non trovato, ecc.).

import { jwtVerify, importSPKI } from 'jose'
import { readFile } from 'node:fs/promises'

const token = 'eyJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.payload.signature'
const publicKeyPem = await readFile('public.pem', 'utf8')

try {
  const { payload, protectedHeader } = await jwtVerify(
    token,
    await importSPKI(publicKeyPem, 'RS256'),
    {
      issuer: 'https://idp.example.com',
      audience: 'my-app',
      algorithms: ['RS256'],     // critico: la whitelist di algoritmi blocca gli attacchi alg:none e di sostituzione HS256
    }
  )
  console.log('alg =', protectedHeader.alg)
  console.log('sub  =', payload.sub)
} catch (err) {
  console.error('verify failed:', err.code, err.message)
  // comune: ERR_JWT_EXPIRED / ERR_JWS_INVALID / ERR_JWS_SIGNATURE_VERIFICATION_FAILED
}

Python: analizza un token e stampa i suoi Claims con PyJWT

python

Il modo più comune per debuggare JWT lato Python. decode() di PyJWT convalida exp / nbf / iat per impostazione predefinita e restituisce il risultato come un semplice dict.

import jwt

token = 'eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxw'

# Analizza (senza verifica della firma, guarda solo Header e Payload)
print(jwt.get_unverified_header(token))
# {'alg': 'HS256', 'typ': 'JWT'}

print(jwt.decode(token, options={'verify_signature': False}))
# {'sub': '1234'}

# Verifica completa
claims = jwt.decode(
    token,
    'my-super-secret-key',
    algorithms=['HS256'],
    audience='my-app',
    issuer='my-service',
)
print(claims['sub'])

Supported Video Formats

FormatMIMEBrowser supportWhen to use
HS256 / HS384 / HS512HMAC + SHA-256/384/512UniversalAlgoritmo a chiave simmetrica. Lo stesso Secret firma e verifica, semplice e veloce, adatto a cluster di servizi all'interno di un limite di fiducia. Il Secret deve essere di almeno 32 byte casuali.
RS256 / RS384 / RS512RSASSA-PKCS1-v1_5 + SHA-2Web Crypto APIL'algoritmo asimmetrico più comune. Firma con la chiave privata, verifica con la chiave pubblica. Predefinito per la maggior parte degli IdP OIDC, gateway API e SSO aziendale.
PS256 / PS384 / PS512RSA-PSS + SHA-2Web Crypto APIRSA-PSS è il sostituto aggiornato e più sicuro di RS256. AWS SigV4, AWS Cognito e i provider OIDC moderni tendono a preferirlo. saltLength deve essere specificato esplicitamente.
ES256 / ES384 / ES512ECDSA + P-256/P-384/P-521Web Crypto APIFirme a curva ellittica. Firme corte (ES256 è solo 64 byte), prestazioni veloci, JWT più piccoli. Apple Sign in with Apple usa ES256 per impostazione predefinita.
EdDSA (Ed25519)Ed25519 / Ed448Web Crypto APIAlgoritmo di firma ad alte prestazioni di nuova generazione. Firme deterministiche (stesso messaggio + stessa chiave producono sempre lo stesso risultato), nessun rischio di riutilizzo del nonce, raccomandato da OAuth 2.1.

Output Example

A real MP3 file encoded to a Data URI — copy-ready:

Header (Base64URL):  eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
Payload(Base64URL):  eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNzE2MjM5MDIyfQ
Signature:           kZJfaYjK3iCkVFL5EL9zGRZ5SmD8_x2h6B5c7pVFfVGo

Header decodificato:
  {
    "alg": "HS256",
    "typ": "JWT"
  }

Payload decodificato:
  {
    "sub": "1234567890",
    "name": "Jane Doe",
    "iat": 1716239022        // 2024-05-20 14:23:42 UTC
  }

Privacy & Security

Questo banco di lavoro JWT viene eseguito al 100% nel tuo browser, supportato dall'API Web Crypto nativa del browser. Il token che incolli, l'Header, il Payload, la Signature, il Secret HMAC, qualsiasi chiave privata RSA/ECDSA, qualsiasi coppia di chiavi generata e ogni calcolo di firma/verifica rimangono sul tuo dispositivo — non viaggiano mai verso un server, non vengono mai registrati, mai analizzati e mai memorizzati nella cache. La pagina può essere usata offline una volta caricata. Migliori pratiche: non incollare mai token di produzione a lunga durata o chiavi private di produzione in nessuno strumento online, incluso questo. Questo strumento è appropriato per debug, test di integrazione, apprendimento e creazione di token di test — i secret di produzione e le chiavi private devono essere gestiti in un ambiente controllato e locale.

Authoritative References

Troubleshooting

Firma non valida: 'signature is invalid'

Il token e la chiave di verifica non corrispondono. Le cause abituali: (1) la chiave del server e la chiave che hai incollato nello strumento sono diverse (il più comune); (2) la chiave contiene caratteri invisibili (spazio finale, ritorno a capo, carattere a larghezza zero); (3) Base64 e Base64URL sono mescolati; (4) è selezionato l'algoritmo sbagliato (Header dice HS256, il server verifica come RS256, o viceversa). Prima verifica che la chiave corrisponda byte per byte: presta attenzione ai ritorni a capo finali del PEM, agli spazi finali del Secret HMAC e ai valori `k` di JWK che potrebbero essere stati decodificati per URL in modo errato. Conferma che l'algoritmo nello strumento corrisponda al Header.alg del token. Usa la funzione di decodifica più verifica di questo strumento per riprodurre l'errore esatto e confermare che si verifica tra 'decodifica riuscita' e 'verifica fallita'.

HTTP 401 Unauthorized: Token scaduto o iat nel futuro

La verifica della firma è passata, ma `exp` è nel passato (Token scaduto), `nbf` è ancora nel futuro (Non prima), o `iat` è successivo all'ora corrente del server (spesso dovuto a desincronizzazione dell'orologio). Un altro caso comune è un `aud` (pubblico) discordante: il token è stato emesso per l'App A ma è convalidato dall'App B. Usa l'area dei Claims evidenziati di questo strumento per individuare lo stato di exp / nbf / iat a colpo d'occhio. exp rosso = scaduto, per favore riemetti. nbf rosso = non ancora valido, verifica se iat è un'ora futura. aud rosso = pubblico errato, verifica che il server abbia il pubblico corretto configurato.

Errore di importazione PEM o JWK

PEM ha righe vuote aggiuntive o mancano marcatori di intestazione/piè di pagina (`-----BEGIN PUBLIC KEY-----`); JWK manca di campi richiesti (`kty` / `n` / `e` / `kid`); il valore `k` di JWK manca di padding Base64URL (deve essere riempito con `=` o strettamente senza `=`); una chiave privata RSA viene importata come chiave pubblica; una chiave privata Ed25519 (seed di 32 byte) viene fornita come 64 byte. Riesporta un PEM PKIX standard con `openssl rsa -in key.pem -pubout -outform PEM` o `openssl ec -in key.pem -pubout`; per JWK, usa l'output grezzo dell'endpoint OIDC Discovery `/.well-known/jwks.json` invece di codificarlo a mano. Questo strumento rileva automaticamente intestazioni PEM, padding mancante e campi JWK mancanti e mostra un suggerimento.

Fallimenti di firma tra RS256 e PS256 tra linguaggi

RS256 usa RSASSA-PKCS1-v1_5, PS256 usa RSA-PSS. I due **non possono verificarsi incrociatamente** — un token firmato con RS256 da una data chiave RSA fallirà sempre la verifica PS256, e la firma può differire in lunghezza di alcuni byte. Assicurati che il firmatario e il verificatore usino lo stesso algoritmo. AWS SigV4 usa PS256, la maggior parte degli IdP OIDC usa RS256. RSA-PSS ha anche un parametro `saltLength` — OpenSSL usa 32 per impostazione predefinita, jose usa 32, `rsa.PSSOptions{SaltLength: rsa.PSSSaltLengthEqualsHash}` di Go è l'equivalente corretto. Blocca questo prima dei test di integrazione tra linguaggi.

Attacco alg:none e attacco di sostituzione della chiave HS256

Il server sceglie un algoritmo di verifica basato sull'alg dichiarato nell'Header del token. Un attaccante riscrive l'header a `alg: none` (nessuna firma) o riscrive un token RS256 in HS256 (usando la chiave pubblica come se fosse un Secret HMAC condiviso) e aggira la verifica. CVE storici come CVE-2015-9235 (jsonwebtoken) e CVE-2022-23529 (molteplici librerie Node) risalgono a questo modello. Il server deve applicare una whitelist di algoritmi — ad esempio `algorithms: ['RS256']` — e non deve mai lasciare che il token dica al server quale algoritmo usare. L'interfaccia di questo strumento mostra sia Header.alg che l'algoritmo che hai effettivamente selezionato, e segnala le mancata corrispondenza: questa è di per sé una dimostrazione dal vivo di 'il client non deve fidarsi di Header.alg'.