Was dieses Tool macht
Dieser JWT-Encoder signiert einen JSON Web Token vollständig in deinem Browser. Wähle einen Algorithmus, bearbeite Header und Payload, füge deinen Signaturschlüssel ein (ein Shared Secret für HMAC; ein PKCS#8-PEM-Private-Key für RSA oder ECDSA) und erhalte einen vollständig signierten Token, den du in eine Anfrage, eine Test-Fixture oder eine Konfiguration einfügen kannst.
Unterstützte Algorithmen: HS256/384/512, RS256/384/512, PS256/384/512, ES256/384/512 sowie EdDSA (Ed25519). alg: none wird ebenfalls unterstützt, aber die Oberfläche markiert es als das Sicherheitsrisiko, das es ist (unsignierter Token).
Die Schlüssel-Eingabe akzeptiert das, was die meisten CLI-Tools tatsächlich ausgeben. RSA-Private-Keys können als PKCS#8 (BEGIN PRIVATE KEY) oder als PKCS#1 (BEGIN RSA PRIVATE KEY) eingefügt werden — TaskKit verpackt den PKCS#1-Body mit einem kleinen eingebauten ASN.1-Reader in PKCS#8, bevor er an WebCrypto geht. Kein openssl pkcs8 -topk8-Schritt nötig. EdDSA akzeptiert den 32-Byte-Private-Seed als 64 Hex-Zeichen, 43 base64url-Zeichen, JWK oder PKCS#8-PEM. Verschlüsselte PKCS#8-Schlüssel (BEGIN ENCRYPTED PRIVATE KEY) werden mit einem einzeiligen Entschlüsselungs-Hinweis abgelehnt; SEC1-EC-Private-Keys (BEGIN EC PRIVATE KEY) mit einem einzeiligen Konvertierungs-Hinweis.
Wann du es brauchst
- Token für einen lokalen Integrationstest erzeugen, bei dem du beide Seiten kontrollierst.
- Eine Fixture für einen Unit-Test produzieren, die einen Token-förmigen String mit echter Signatur braucht.
- Einen Bug reproduzieren, indem du einen Claim änderst und mit demselben Schlüssel neu signierst.
- Ein Beispiel-Token für einen Teammate erzeugen, ohne das Geheimnis auf einer fremden Seite einzugeben.
Wie es funktioniert
Das Signieren nutzt crypto.subtle.sign — die in den Browser eingebaute WebCrypto-API. HMAC-Schlüssel werden aus Rohbytes importiert; RSA- und ECDSA-Private-Keys als PKCS#8 (PKCS#1 wird automatisch konvertiert). EdDSA nutzt @noble/ed25519, da WebCryptos Ed25519-Unterstützung noch lückenhaft ist. Der Encoder baut base64url(header).base64url(payload).base64url(signature) — das ist der Token.
Das alg-Feld im Header wird immer auf den gewählten Algorithmus gesetzt, auch wenn du im Header-Feld etwas anderes geschrieben hast. typ: "JWT" wird per Default ergänzt, wenn nicht vorhanden. Benutzerdefinierte Header-Felder (kid, x5t, beliebige andere) bleiben erhalten.
Header, Payload und Signaturschlüssel verlassen den Browser nicht. Es gibt keinen Server-Schritt.
Hinweise
Woher bekomme ich einen Private-Key? Für RSA: openssl genpkey -algorithm RSA -out private.pem -pkeyopt rsa_keygen_bits:2048 erzeugt einen PKCS#8-PEM (BEGIN PRIVATE KEY). Ältere PKCS#1-Blöcke (BEGIN RSA PRIVATE KEY) werden direkt akzeptiert — kein Konvertierungsschritt nötig. Für EdDSA: openssl genpkey -algorithm Ed25519 funktioniert; TaskKit liest den resultierenden PKCS#8-PEM. SEC1-EC-Private-Keys (BEGIN EC PRIVATE KEY) müssen vorher mit openssl pkcs8 -topk8 -nocrypt -in sec1.pem -out pkcs8.pem umgewandelt werden.
Soll ich Tokens mit alg: none signieren? Praktisch nie. Der unsignierte Token hat keinen Integritätsschutz, und jeder Verifier, der ihn akzeptiert, ist trickbar. Der Encoder erzeugt ihn der Vollständigkeit halber und warnt explizit; Ergebnis nur für Tests verwenden.
HS oder RS für neuen Code? RS256 (oder ES256), wenn ein externer Verifier prüfen soll — der braucht nur den Public Key. HS256, wenn derselbe Service auf beiden Seiten steht.
Verwandte Tools
- JWT-Decoder — Token einfügen und prüfen oder verifizieren
- Hash-Generator — wenn du wirklich einen Digest brauchst, keinen Token
- Timestamp-Konverter — für lesbare
exp- undiat-Werte