Cosa fa questo strumento
Questo encoder JWT firma un JSON Web Token interamente nel tuo browser. Scegli un algoritmo, modifica header e payload, incolla la tua chiave di firma (un segreto condiviso per HMAC; una chiave privata PEM PKCS#8 per RSA o ECDSA) e ottieni un token firmato completo, pronto da incollare in una richiesta, una fixture o una config.
Algoritmi supportati: HS256/384/512, RS256/384/512, PS256/384/512, ES256/384/512 ed EdDSA (Ed25519). alg: none è anch'esso supportato, ma l'UI lo segnala come il rischio di sicurezza che è (token non firmato).
L'input della chiave accetta ciò che la maggior parte degli strumenti CLI emette davvero. Le chiavi private RSA possono essere incollate come PKCS#8 (BEGIN PRIVATE KEY) o come PKCS#1 (BEGIN RSA PRIVATE KEY) — TaskKit avvolge il corpo PKCS#1 in PKCS#8 con un piccolo lettore ASN.1 interno prima di passarlo a WebCrypto, senza richiedere un passaggio openssl pkcs8 -topk8. EdDSA accetta il seed privato di 32 byte come 64 caratteri hex, 43 caratteri base64url, JWK o PEM PKCS#8. Le chiavi PKCS#8 cifrate (BEGIN ENCRYPTED PRIVATE KEY) vengono rifiutate con un suggerimento di decifratura su una riga; le chiavi private EC SEC1 (BEGIN EC PRIVATE KEY) vengono rifiutate con un suggerimento di conversione su una riga.
Quando usarlo
- Generare un token per un test di integrazione locale dove controlli entrambi i lati.
- Produrre una fixture per un test unitario che ha bisogno di una stringa con la forma di un token e una vera firma.
- Riprodurre un bug da un token funzionante modificando un claim e rifirmando con la stessa chiave.
- Costruire un token di esempio per un collega durante una sessione di debug, senza esporre il segreto su un sito condiviso.
Come funziona
La firma usa crypto.subtle.sign, l'API WebCrypto integrata nel browser. Le chiavi HMAC vengono importate da byte grezzi; le chiavi private RSA ed ECDSA vengono importate come PKCS#8 (PKCS#1 viene convertito al volo). EdDSA passa per @noble/ed25519 perché il supporto WebCrypto per Ed25519 è ancora irregolare. L'encoder costruisce base64url(header).base64url(payload).base64url(firma) e quello è il token.
Il campo alg dell'header viene sempre sovrascritto per corrispondere all'algoritmo scelto, anche se hai scritto qualcosa di diverso nel textarea dell'header. typ: "JWT" viene aggiunto di default se non l'hai incluso. I campi personalizzati dell'header (kid, x5t, qualsiasi altro) vengono preservati.
Header, payload e chiave di firma non lasciano mai il tuo browser. Non c'è passaggio server.
Note
Dove trovo una chiave privata? Per RSA: openssl genpkey -algorithm RSA -out private.pem -pkeyopt rsa_keygen_bits:2048 produce un PEM PKCS#8 (BEGIN PRIVATE KEY). I blocchi PKCS#1 più vecchi (BEGIN RSA PRIVATE KEY) vengono accettati direttamente — nessun passaggio di conversione. Per EdDSA: openssl genpkey -algorithm Ed25519 funziona e TaskKit legge il PEM PKCS#8 risultante. Le chiavi private EC SEC1 (BEGIN EC PRIVATE KEY) devono essere convertite prima con openssl pkcs8 -topk8 -nocrypt -in sec1.pem -out pkcs8.pem.
Dovrei firmare token con alg: none? Quasi mai. Il token non firmato non ha protezione di integrità e qualsiasi verificatore che lo accetti può essere ingannato. L'encoder lo produce per completezza e avverte esplicitamente; tratta il risultato come solo-per-test.
HS o RS per nuovo codice? RS256 (o ES256) quando una parte esterna verifica — le serve solo la chiave pubblica. HS256 quando lo stesso servizio è da entrambi i lati.
Strumenti correlati
- Decodificatore JWT — incolla un token per ispezionarlo o verificarlo
- Generatore di hash — se vuoi davvero un digest, non un token
- Convertitore timestamp — per valori
expeiatleggibili