Einen signierten JSON Web Token (JWT) erstellen

Was ist JWT Builder?

JWT Builder ist ein Online-Tool, das einen signierten JSON Web Token (JWT) aus einem JSON-Payload und einem HMAC-Secret erzeugt. Es richtet sich an Entwickler, die schnell einen Test-Token erzeugen müssen, um das Verhalten einer API zu prüfen, eine authentifizierte Session in Postman zu simulieren oder einen Bug im Zusammenhang mit Ablauf oder Geltungsbereich eines Tokens zu reproduzieren.

Anders als unser JWT-Decoder, der sich darauf beschränkt, ein bestehendes Token zu lesen, baut JWT Builder ein komplettes Token: Er konstruiert den Header, kodiert das Payload, berechnet die HMAC-Signatur und setzt alles im Kompaktformat header.payload.signature zusammen, das von allen JWT-Bibliotheken auf dem Markt erwartet wird.

Warum ein JWT erzeugen?

Ein JWT-Builder soll keine Produktions-Tokens ausstellen. Er ist vor allem ein Entwicklungs- und Test-Tool. Hier sind die häufigsten Szenarien:

• Integrationstests: vorhersehbare JWTs erzeugen, um E2E-Tests gegen geschützte Endpoints zu steuern, ohne vom echten Identity Provider abhängig zu sein.
• API-Mocks: einen IdP-Aufruf vorübergehend durch ein lokal mit demselben Test-Secret signiertes JWT ersetzen.
• Lokale Entwicklung: sich mit dem eigenen Backend verbinden, indem man manuell ein Token mit den gewünschten Claims erzeugt, ohne den gesamten OAuth2-Flow durchlaufen zu müssen.
• Demos: einen Authentifizierungsweg oder einen berechtigungsbasierten Workflow illustrieren, ohne einen echten IdP zur Hand zu haben.
• Bug-Reproduktion: ein abgelaufenes Token, ein Token mit falschem aud, ein Token ohne bestimmte Claims schmieden, um die Fehlerpfade Ihrer API zu testen.
• Debugging eines Custom-Parsers: speziell konstruierte JWTs injizieren, um einen eigenen Parser zu testen.

Zusammensetzung eines JWT

Ein signiertes JWT besteht aus drei durch einen Punkt getrennten Segmenten, jedes in Base64URL kodiert (Base64-Variante ohne Padding und mit -/_ statt +//):

• Header: ein JSON-Objekt, das den Signaturalgorithmus und den Tokentyp beschreibt, zum Beispiel {"alg":"HS256","typ":"JWT"}. JWT Builder erzeugt ihn automatisch aus dem von Ihnen gewählten Algorithmus.
• Payload: ein beliebiges JSON-Objekt, das die Claims des Tokens enthält (Subject, Berechtigungen, Ablaufdaten). Das ist der Teil, den Sie bereitstellen.
• Signatur: ein HMAC-SHA, berechnet über die Verkettung base64url(header) + "." + base64url(payload) mit Ihrem geheimen Schlüssel. Sie garantiert die Integrität des Tokens.

Anwendungsfälle im Detail

• API-Mock für E2E-Tests: Ihre Cypress- oder Playwright-Suite muss eine API aufrufen, die ein Authorization: Bearer ... verlangt. Statt bei jedem Test einen vollständigen Login zu orchestrieren, signiert man spontan ein JWT mit dem gemeinsamen Secret und fügt es in den Header ein.
• SSO-Demo: einen föderierten Authentifizierungsweg präsentieren, ohne von einem Online-IdP abhängig zu sein.
• Test-Fixture: ein deterministisches JWT aus einem bekannten Payload erzeugen, um als stabile Fixture in Unit-Tests zu dienen.
• Diagnose eines Custom-Parsers: einen eigenen JWT-Parser mit absichtlich minimalen oder absichtlich seltsamen Tokens testen (fehlende Claims, unerwartete Typen).
• Lernen: konkret verstehen, wie ein JWT konstruiert wird, indem man das Payload ändert und beobachtet, wie sich die Signatur verändert.

Unterstützte Algorithmen: HS256, HS384, HS512

Unser Tool unterstützt die drei HMAC-Standardalgorithmen der JWT-Spezifikation (RFC 7519):

• HS256: HMAC mit SHA-256. Signatur von 32 Bytes. Am häufigsten in der Praxis verwendet, guter Kompromiss zwischen Geschwindigkeit und kryptografischer Stärke. Standardempfehlung.
• HS384: HMAC mit SHA-384. Signatur von 48 Bytes. Geeignet für Kontexte, die eine höhere Sicherheitsmarge verlangen.
• HS512: HMAC mit SHA-512. Signatur von 64 Bytes. Am robustesten, zum Preis eines etwas größeren Tokens.

HMAC oder RSA?

Die HS*-Algorithmen sind symmetrisch: Derselbe Schlüssel dient zum Signieren und Überprüfen. Das ist einfach und schnell, bedeutet aber, dass jeder Dienst, der ein Token überprüfen kann, auch eines ausstellen kann. Wenn Sie diese beiden Rollen trennen müssen (ein einziger Aussteller, mehrere Konsumenten), wenden Sie sich den RS256/RS384/RS512-Algorithmen (RSA, asymmetrisch) zu, die Sie mit unserem JWT Verifier überprüfen können.

Sicherheit: Ihr Secret schützen

Die Sicherheit eines in HMAC signierten JWT beruht vollständig auf der Vertraulichkeit des Secrets. Einige Grundregeln:

• Verwenden Sie ein langes und zufälliges Secret. Die RFC 7518 empfiehlt mindestens die Größe der Algorithmus-Ausgabe (32 Bytes für HS256, 48 für HS384, 64 für HS512). Ein menschliches Passwort wie azerty123 ist trivial offline brute-force-angreifbar.
• Signieren Sie ein JWT niemals clientseitig. Das Secret würde im an den Browser ausgelieferten JavaScript-Code stehen, für jeden Benutzer sichtbar. Die Signatur muss immer serverseitig bleiben.
• Speichern Sie das Secret in einer Umgebungsvariablen (z. B. JWT_SECRET), niemals in einem Git-Repository. Denken Sie daran, je nach Stack einen Vault wie HashiCorp Vault, AWS Secrets Manager oder Symfony Secrets zu verwenden.
• Rotieren Sie das Secret regelmäßig (Key Rotation), insbesondere nach jedem Vorfall oder Weggang einer Person, die Zugriff auf die Konfiguration hatte.
• JWT Builder ist für Tests und Lernen bestimmt. Für die Produktion verwenden Sie die JWT-Bibliothek Ihres Frameworks (lcobucci/jwt, firebase/php-jwt, jose-php).

Claims-Best-Practices

Das Payload ist ein freies JSON-Objekt, aber die RFC 7519 definiert eine Reihe von registered claims, die JWT-Bibliotheken interpretieren können. Die richtigen Claims einzufügen macht Ihr Token portabel und vermeidet subtile Bugs:

• iss (issuer): Bezeichner des Ausstellers, zum Beispiel "https://api.example.com".
• sub (subject): Bezeichner der betroffenen Person oder Entität, oft die Benutzer-ID.
• aud (audience): an wen das Token gerichtet ist, um die Wiederverwendung eines Tokens auf einer anderen API zu verhindern.
• exp (expiration time): Unix-Timestamp, nach dem das Token nicht mehr gültig ist. Immer einschließen, auch bei einem Test-Token: Ein Token ohne Ablauf ist eine schwer zu korrigierende schlechte Angewohnheit.
• nbf (not before): Timestamp, vor dem das Token noch nicht gültig ist. Nützlich, um ein später aktivierbares Token vorab auszustellen.
• iat (issued at): Ausstellungs-Timestamp, nützlich für Logging und Widerruf.
• jti (JWT ID): eindeutiger Token-Bezeichner, unverzichtbar für Idempotenz und zur Implementierung einer Widerrufsliste.

Beispiel eines typischen Payload

{
  "iss": "https://api.example.com",
  "sub": "user-12345",
  "aud": "mobile-app",
  "iat": 1714723200,
  "exp": 1714726800,
  "jti": "9f2d6b1e-2c4a-4f8a-9c3a-87a2b8a4b7e1",
  "scope": "read:profile write:profile"
}

So verwenden Sie das Tool

1. Geben Sie das Payload als gültiges JSON ein. Es ist ein Objekt, beginnt also mit { und endet mit }.
2. Geben Sie das HMAC-Secret an. Wählen Sie eine lange und zufällige Zeichenkette für Produktions-Tokens.
3. Wählen Sie den Algorithmus: HS256 standardmäßig, HS384 oder HS512 je nach Bedarf.
4. Klicken Sie auf erstellen. Das signierte JWT erscheint, fertig zum Einfügen in einen Authorization: Bearer ...-Header.
5. Sie können das Token dann mit demselben Secret überprüfen, um die Round-Trip-Konsistenz zu bestätigen, oder es dekodieren, um den Inhalt erneut zu lesen.

Häufig gestellte Fragen

Beispielanfrage

curl -X POST https://cdrn.fr/api/v1/tools/jwt-builder/execute \
  -H "Content-Type: application/json" \
  -d '{"payload":"...","secret":"...","algorithm":"HS256"}'

Eingabeschema

Endpunkte

• GET https://cdrn.fr/api/v1/tools - listet alle verfügbaren Tools auf
• GET https://cdrn.fr/api/v1/tools/jwt-builder - liefert das Schema dieses Tools
• POST https://cdrn.fr/api/v1/tools/jwt-builder/execute - führt dieses Tool mit einem JSON-Payload aus