JWT-Token-Generator

So verwendest du den JWT-Token-Generator

1. Bearbeite die Nutzlast. Ersetze das Standard-JSON durch deine Claims. Gängige Standardclaims sind sub (Subjekt), iat (ausgestellt am, Unix-Sekunden), exp (Ablauf, Unix-Sekunden), aud (Zielgruppe), iss (Aussteller), jti (JWT-ID) sowie anwendungsspezifische benutzerdefinierte Claims.
2. Gib das HMAC-Geheimnis ein oder fuge es ein. Das ist derselbe Schlüssel, den der Prüfer zur Validierung des Tokens verwenden wird. RFC 7518 empfiehlt einen Schlüssel, der mindestens so groß wie die Hash-Ausgabe ist (32 Byte für HS256, 48 für HS384, 64 für HS512).
3. Wahle den Algorithmus - HS256 (der OAuth/OIDC-Standard), HS384 oder HS512. Passe an, was der Prüfer in seiner alg-Erlaubnisliste erwartet.
4. Drucke auf "iat + exp hinzufugen", um die Standard-Zeit-Claims mit einem Klick einzufugen. Standard setzt exp eine Stunde nach iat.
5. Drucke auf "Generieren" und das signierte JWT erscheint unten. Drucke auf "Kopieren", um es in die Zwischenablage zu legen, bereit zum Einfugen in ein curl -H "Authorization: Bearer ..."-Flag, einen Postman-Tab oder einen Fetch-Test.

Was der Generator intern tut

Das Tool baut die kanonische dreiteilige JWT-Struktur auf, die durch RFC 7519 (JWT) und RFC 7515 (JWS Compact Serialization) definiert ist: base64url(header).base64url(payload).base64url(HMAC(signingInput, key)). Der Header ist immer {"alg": "<algorithmus>", "typ": "JWT"}, dann JSON-stringifiziert und base64url-kodiert ohne Auffüllung. Die Nutzlast ist das JSON, das du eingegeben hast, ebenfalls base64url-kodiert. Die Signing-Eingabe sind die ersten beiden Segmente, verbunden mit einem Punkt. Die Signatur wird mit crypto.subtle.sign("HMAC", key, signingInput) uber die Web Crypto API berechnet und dann auf dieselbe Weise base64url-kodiert.

Die subtle.sign-Funktion der Web Crypto API unterstützt HMAC mit der CSPRNG-Qualitatsimplementierung des Browsers: BoringSSL auf Chromium, NSS auf Firefox, CommonCrypto auf Safari. Der HMAC-Schlüssel wird uber subtle.importKey("raw", textEncoder.encode(secret), { name: "HMAC", hash: "SHA-256" }, false, ["sign"]) importiert, mit extractable: false, sodass selbst die Seite nach dem Import die Schlusselbytes nicht lesen kann. Die gesamte Pipeline ist eine async-Funktion ohne Netzwerkabrufe; du kannst das verifizieren, indem du die DevTools offnest, zum Netzwerk-Tab wechselst und auf "Generieren" druckst.

Wann dieses Tool seinen Nutzen zeigt

• Erstellen eines Test-Tokens für eine lokale API, die einen Bearer-JWT erwartet, wenn du kein Node-Skript aufsetzen mochtest, nur um einen zu erstellen.
• Reproduzieren eines Fehlers aus einem Produktions-Token durch erneutes Signieren derselben Nutzlast mit einem bekannten Entwicklungsgeheimnis zum Vergleich des Verhaltens.
• Demonstration der JWT-Struktur in einem Workshop oder Einarbeitungs-Session: Nutzlast eingeben, signieren, dekodieren, auf die drei Segmente hinweisen.
• Kombination mit dem JWT-Decoder auf dieser Seite für einen Rund-Trip: generieren, kopieren, in den Decoder einfugen, bestatigen, dass die Claims identisch zuruckgelesen werden.
• Erstellen eines Tokens mit absichtlich ungiiltigen Claims (abgelaufenes exp, nicht ubereinstimmendes aud), um zu testen, dass dein Prüfer diese ablehnt.
• Generieren eines Fixture-Tokens für einen Integrationstest einbetten, bei dem das Test-Setup vor jeder Suite einen frischen JWT erstellt.

Haufige Fallstricke und Randfalle

• HMAC-Geheimnisse sind symmetrisch. Jede Partei mit dem Geheimnis kann Tokens falschlich signieren. Behandle HS256-Geheimnisse als Produktionsanmeldedaten und ubergib sie niemals an Git oder schreibe sie in Logs. Für mehrere Dienste wechsle zu RS256 oder EdDSA, die von diesem Tool nicht bereitgestellt werden, da private Schlüssel kein sicheres Szenario in einem Browser haben.
• Zeit-Claims sind Ganzzahlen, keine Zeichenketten. "exp": 1735689600 ist korrekt; "exp": "2025-01-01T00:00:00Z" ist gemas RFC 7519 ungultig. Der "iat+exp hinzufugen"-Helfer des Tools fug die richtige Form automatisch ein.
• Leerzeichen am Ende des Geheimnisses unterbrechen die Verifizierung. Der haufigste False-Positive-Fehler ist ein kopiertes Geheimnis mit einem versteckten Zeilenumbruch; verifiziere, indem du das Geheimnis direkt hashst und es mit der Sicht des Prufers vergleichst.
• Der "alg: none"-Angriff ist bekannt: Ein JWT, das ohne Signatur signiert ist, kann Prufer passieren, die die alg-Erlaubnisliste nicht durchsetzen. Dieser Generator stellt alg=none nicht bereit, aber wenn du einen Prüfer testest, konstruiere manuell einen Token mit {"alg":"none"} und einem leeren Signatur-Segment, um zu bestatigen, dass er abgelehnt wird.
• JWE ist eine andere Spezifikation. JWT selbst ist unverschlusselt; die Nutzlast ist für jeden, der den Token sieht, base64url-dekodierbar. Um die Nutzlast zu verschlusseln, verwende JWE (RFC 7516); das Tool hier signiert nur.
• Die Header-Reihenfolge ist wichtig für die Signatur. Die erneute Kodierung desselben JWT mit umgeordneten Header-Schlusseln erzeugt eine andere Signatur, obwohl die strukturelle Bedeutung identisch ist. Signiere immer die kanonische Form, die dein Prüfer erwartet.

JWT, JWS, JWA: die Standards hinter den Tokens

JWT (RFC 7519, 2015) ist eine kompakte, URL-sichere Darstellung von Claims als JSON-Objekt. JWS (RFC 7515) definiert das Signierformat - die dreiteilige, durch Punkte getrennte Struktur. JWA (RFC 7518) zahlt die kryptografischen Algorithmen auf, die jede Implementierung akzeptieren muss. Die HS256-Familie verwendet HMAC uber SHA-2, definiert durch FIPS 198-1. RS256 verwendet RSASSA-PKCS1-v1_5; ES256 verwendet ECDSA uber P-256; EdDSA verwendet Ed25519 gemas RFC 8037. Die OAuth-2.0- (RFC 6749) und OpenID-Connect-Spezifikationen verwenden standardmasig JWT für Zugriffstoken und ID-Token, was der Grund ist, warum das Format in modernen Authentifizierungsflussen allgegenwärtig ist. Die kompakte Serialisierung in diesem Tool ist die haufigste; JWS definiert auch eine JSON-Serialisierung für Anwendungsfalle, die getrennte oder Mehrfachempfanger-Signaturen benotigen.

Alternativen und wann sie dieses Tool ubertreffen

Die Node-Bibliothek jsonwebtoken ist der Standard für serverseitiges Signieren und Verifizieren, mit einer reichhaltigeren Claim-Helfer-API und eingebauter Uhrversatz-Toleranz. jose auf npm deckt die gesamte JOSE-Spezifikationsfamilie (JWE, JWK, JWKS) ab und ist die richtige Wahl, wenn du asymmetrische Signierung oder Verschlüsselung benotigst. PyJWT ist das Aquivalent in Python, mit expliziten Algorithmus-Erlaubnislisten. Das CLI-Tool jwt-cli (Rust) signiert und dekodiert aus einer Shell. jwt.io ist die bekannte Web-Referenz, sendet jedoch das Geheimnis an einen Remote-Dienst, was der Grund ist, warum dieses Tool lokal existiert. Verwende diesen Generator, wenn du einen schnellen HS256-Token im Browser mochtest, das Einfugen eines Geheimnisses in eine Remote-Seite vermeiden mochtest und es mit dem lokalen JWT-Decoder für einen vollständig auf dem Gerät stattfindenden Rund-Trip kombinieren mochtest.