Encodeur JWT

Ce que fait cet outil

Cet encodeur JWT signe un JSON Web Token entièrement dans ton navigateur. Choisis un algorithme, édite le header et le payload, colle ta clé de signature (un secret partagé pour HMAC ; une clé privée PEM PKCS#8 pour RSA ou ECDSA) et tu obtiens un token signé complet, prêt à coller dans une requête, un fixture ou une config.

Algorithmes supportés : HS256/384/512, RS256/384/512, PS256/384/512, ES256/384/512 et EdDSA (Ed25519). alg: none est aussi supporté, mais l'UI le signale comme le risque de sécurité qu'il est (token non signé).

L'entrée de la clé accepte ce que la plupart des outils CLI émettent vraiment. Les clés privées RSA peuvent être collées en PKCS#8 (BEGIN PRIVATE KEY) ou en PKCS#1 (BEGIN RSA PRIVATE KEY) — TaskKit enveloppe le corps PKCS#1 en PKCS#8 avec un petit lecteur ASN.1 maison avant de le passer à WebCrypto, sans étape openssl pkcs8 -topk8 requise. EdDSA accepte la seed privée de 32 bytes en 64 caractères hex, 43 caractères base64url, JWK ou PEM PKCS#8. Les clés PKCS#8 chiffrées (BEGIN ENCRYPTED PRIVATE KEY) sont rejetées avec une indication de déchiffrement d'une ligne ; les clés privées EC SEC1 (BEGIN EC PRIVATE KEY) sont rejetées avec une indication de conversion d'une ligne.

Quand l'utiliser

• Générer un token pour un test d'intégration local où tu contrôles les deux bouts.
• Produire un fixture pour un test unitaire qui a besoin d'une string en forme de token avec une vraie signature.
• Reproduire un bug à partir d'un token qui marche en modifiant un claim et en re-signant avec la même clé.
• Construire un token d'exemple pour un coéquipier pendant une session de débogage, sans exposer le secret sur un site partagé.

Comment ça marche

La signature utilise crypto.subtle.sign, l'API WebCrypto intégrée au navigateur. Les clés HMAC sont importées en bytes bruts ; les clés privées RSA et ECDSA sont importées en PKCS#8 (PKCS#1 est converti à la volée). EdDSA passe par @noble/ed25519 parce que le support WebCrypto pour Ed25519 reste irrégulier. L'encodeur construit base64url(header).base64url(payload).base64url(signature) et c'est ça le token.

Le champ alg du header est toujours réécrit pour correspondre à l'algorithme choisi, même si tu as tapé autre chose dans le textarea du header. typ: "JWT" est ajouté par défaut si tu ne l'as pas inclus. Les champs personnalisés du header (kid, x5t, n'importe quel autre) sont préservés.

Le header, le payload et la clé de signature ne quittent jamais ton navigateur. Il n'y a pas d'étape serveur.

Notes

Où je trouve une clé privée ? Pour RSA : openssl genpkey -algorithm RSA -out private.pem -pkeyopt rsa_keygen_bits:2048 produit un PEM PKCS#8 (BEGIN PRIVATE KEY). Les anciens blocs PKCS#1 (BEGIN RSA PRIVATE KEY) sont acceptés directement — pas d'étape de conversion. Pour EdDSA : openssl genpkey -algorithm Ed25519 marche et TaskKit lit le PEM PKCS#8 résultant. Les clés privées EC SEC1 (BEGIN EC PRIVATE KEY) doivent être converties d'abord avec openssl pkcs8 -topk8 -nocrypt -in sec1.pem -out pkcs8.pem.

Devrais-je signer des tokens avec alg: none ? Quasi jamais. Le token non signé n'a pas de protection d'intégrité et n'importe quel vérificateur qui l'accepte peut être trompé. L'encodeur le produit pour la complétude et avertit explicitement ; traite le résultat comme test-only.

HS ou RS pour du nouveau code ? RS256 (ou ES256) quand une partie externe vérifie — il lui suffit de la clé publique. HS256 quand le même service est des deux côtés.

Outils liés

• Décodeur JWT — colle un token pour l'inspecter ou le vérifier
• Générateur de hash — si tu veux vraiment un digest, pas un token
• Convertisseur timestamp — pour des valeurs exp et iat lisibles