Kostenloser JWT-Generator

Was ein JWT tatsächlich ist

Ein JSON Web Token (JWT), ausgesprochen „dschott“, ist eine kompakte, URL-sichere Darstellung von Claims, die zwischen zwei Parteien übertragen werden. Das Format besteht aus drei Base64url-kodierten Segmenten, durch Punkte getrennt: Header.Payload.Signatur. Der Header deklariert den Token-Typ (immer JWT) und den Signaturalgorithmus (häufig HS256, RS256 oder ES256). Der Payload trägt die Claims, ein JSON-Objekt mit Standardfeldern wie iss (Issuer), sub (Subject), aud (Audience), exp (Ablaufzeit als Unix-Timestamp), nbf (not before), iat (issued at), jti (JWT-ID), plus alle anwendungsspezifischen Claims, die der Issuer aufnehmen will. Die Signatur ist der kryptographische Beweis, dass Header und Payload nicht manipuliert wurden, erzeugt durch Signieren der verketteten base64url(Header).base64url(Payload)-Zeichenkette mit dem im Header deklarierten Algorithmus und Schlüssel. JWT wurde von Michael B. Jones, John Bradley und Nat Sakimura als RFC 7519 im Mai 2015 spezifiziert, aufbauend auf der vorherigen Arbeit in JOSE (JSON Object Signing and Encryption, RFCs 7515 bis 7520). Das Format ist die dominierende Token-Form in moderner Web-Authentifizierung geworden, eingesetzt in OAuth-2.0/OIDC-Implementierungen, API-Gateways, SPA-Session-Tokens, Microservice-zu-Microservice-Authentifizierung und cookie-basierter Session-Verwaltung im großen Stil.

Die Wahl des Signaturalgorithmus, HS256 vs. RS256 vs. ES256

JWT unterstützt mehrere Signaturalgorithmen, registriert im JOSE-Algorithmen-Register (RFC 7518). HS256 (HMAC-SHA256) ist der einfachste: ein symmetrischer Algorithmus, bei dem dasselbe Geheimnis zum Signieren und Verifizieren verwendet wird. Günstig zu berechnen, leicht zu implementieren und passend, wenn Signierer und Verifier dieselbe Partei sind (z. B. eine einzelne Anwendung, die sich selbst Session-Tokens ausstellt). RS256 (RSA-SHA256) ist asymmetrisch: der private Schlüssel signiert, der öffentliche Schlüssel verifiziert. Eingesetzt, wenn Issuer und Verifier verschiedene Parteien sind, Auth0, Okta, Google Identity Platform, Microsoft Entra ID und die meisten Cloud-Identitätsanbieter geben RS256-signierte JWTs aus, weil Clients die Signatur über einen veröffentlichten JWKS-Endpunkt (JSON Web Key Set) verifizieren können, ohne Geheimnisse teilen zu müssen. ES256 (ECDSA P-256 SHA-256) ist das elliptische-Kurven-Äquivalent von RS256, gleiches Public/Private-Key-Modell, viel kürzere Schlüssel (256 Bit gegenüber RSAs Minimum von 2048), schnellere Verifikation. EdDSA (Ed25519) ist der moderne Nachfolger von ES256, etwas schneller und mit saubereren kryptographischen Eigenschaften; in neueren JWT-Bibliotheken unterstützt, aber noch nicht universell. none ist ein vom JWT-Spec erlaubter „keine Signatur“-Modus, der über mehrere Bibliotheken hinweg Sicherheitsvorfälle ausgelöst hat, wenn Implementierungen es versäumten, alg: none-Tokens abzulehnen, die Lehre: JWT-Verifier müssen explizit prüfen, dass der Algorithmus dem erwarteten entspricht. Dieser Generator verwendet HS256, weil er nur ein gemeinsames Geheimnis statt Schlüsselgenerierung benötigt; für den produktiven Einsatz asymmetrischer Algorithmen ist eine serverseitige Bibliothek das richtige Werkzeug.

Wann Sie ein JWT von Hand erzeugen müssen

• API-Endpunkte testen. Eine API verlangt ein JWT im Authorization-Header, um sie manuell mit curl, Postman oder HTTPie zu testen, brauchen Sie ein Token. Erzeugen Sie ein Test-JWT in der richtigen Form, signieren Sie es mit dem geteilten Geheimnis der API (in Dev-Umgebungen) und verwenden Sie das Ergebnis.
• Einen tokenbezogenen Bug nachstellen. Ein Nutzer meldet ein Auth-Problem. Rekonstruieren Sie das Token, das er mit seinen Claims erhalten hätte, untersuchen Sie die Signatur, prüfen Sie die Verifikationslogik Ihres Dienstes gegen ein bekannt-gutes und ein bekannt-schlechtes Token.
• Lokale Entwicklung ohne Auth-Provider. Sie bauen ein Frontend gegen eine API, die JWT-Authentifizierung erwartet, haben aber noch keinen Zugriff auf den Produktions-Identity-Provider. Erzeugen Sie Test-JWTs mit realistischen Claims für die Entwicklung.
• Das JWT-Format lernen. Ein JWT decodieren, einen Claim ändern, neu signieren, sehen, was Ihre Anwendung macht. Die Hands-on-Debugging-durch-Herumprobieren-Schleife ist der Weg, auf dem die meisten Entwickler die JWT-Struktur am Ende verstehen.
• Interne Service-zu-Service-Tokens. Zwei interne Microservices teilen ein Geheimnis und nutzen JWT zur Authentifizierung von Anfragen. Das HS256-Shared-Secret-Modell passt hier; dieses Werkzeug kann die Tokens manuell für Tests erzeugen.

Sicherheitsfallen, wo JWTs schiefgehen

JWTs haben eine lange Geschichte von Implementierungsfehlern, die echte Sicherheitsvorfälle ausgelöst haben. Der „alg: none“-Angriff: frühe JWT-Bibliotheken akzeptierten Tokens mit dem Algorithmusfeld auf „none“ (keine Signatur), wodurch ein Angreifer beliebige Tokens fälschen konnte. Verifier müssen den erwarteten Algorithmus explizit erzwingen. Algorithmusverwirrung: ein Verifier, der sowohl RS256 als auch HS256 akzeptiert, kann ausgetrickst werden, indem der öffentliche RSA-Schlüssel als HMAC-Geheimnis verwendet wird, der Angreifer signiert mit HS256 mit dem öffentlichen Schlüssel, der Verifier (fehl-)verifiziert mit HMAC mit demselben öffentlichen Schlüssel. Verifier müssen den erwarteten Algorithmus festpinnen. Sensible Daten im Payload: JWT-Claims sind Base64-kodiert, aber nicht verschlüsselt. Jeder mit dem Token kann jeden Claim lesen. Niemals Passwörter, vollständige Kreditkartennummern oder andere Geheimnisse in den Payload aufnehmen. Keine Ablaufzeit: JWTs ohne exp-Claim sind ewig gültig. Setzen Sie immer eine vernünftige Ablaufzeit (Minuten für Access-Tokens, Tage für Refresh-Tokens). Keine Widerrufsmöglichkeit: JWTs sind selbstständig, einmal ausgegeben, bleiben sie bis exp gültig, egal ob der Nutzer sich abmeldet, sein Passwort ändert oder sein Konto gesperrt wird. Akzeptieren Sie diese Einschränkung, pflegen Sie eine Widerrufsliste (was den stateless-Token-Vorteil teilweise zunichtemacht) oder verwenden Sie kurzlebige Access-Tokens mit Refresh-Token-Rotation. Speicherung in localStorage vs. Cookies: ein JWT im localStorage ist für jedes JavaScript der Seite zugänglich (XSS-Risiko); ein JWT in einem HttpOnly-Cookie nicht (wird aber automatisch mit Cross-Origin-Anfragen gesendet, CSRF-Risiko). Beide haben Trade-offs; moderne Best Practice tendiert zu HttpOnly-Cookies mit SameSite-Beschränkungen plus CSRF-Tokens.

JWT vs. Session-Cookies vs. PASETO

JWT ist nicht die einzige Wahl. Traditionelle Session-Cookies speichern eine intransparente Session-ID; der Server hält den eigentlichen Session-Zustand in einer Datenbank oder einem Cache. Vorteile: triviale Widerrufsmöglichkeit (Server-seitigen Eintrag löschen), kein Risiko des Auslaufens von Claim-Daten, keine Signaturkomplexität. Nachteile: erfordert Session-Store-Lookup pro Anfrage (Latenz), schwerer dienstübergreifend zu skalieren. PASETO (Platform-Agnostic Security Tokens, Scott Arciszewski 2018) ist ein JWT-Ersatz, entworfen, um die Algorithmusverwirrungs- und „none“-Fallen zu vermeiden, versioniertes Format, keine Algorithmus-Aushandlung, verpflichtende Signaturen, eingeschränkte Cipher-Auswahl. PASETO hat in sicherheitssensiblen Kontexten an Boden gewonnen, aber JWT im breiteren Ökosystem nicht verdrängt. Macaroons (Google, 2014) sind ein flexibleres Token-Format mit verkettbaren Capability-Restriktionen, aber 2026 im Wesentlichen Forschungsthema. OAuth 2.1 konsolidiert die Best Practices von OAuth 2.0, JWT ist weiterhin das typische Access-Token-Format. Die pragmatische Wahl 2026 bleibt JWT für stateless Microservices und API-Tokens, intransparente Session-Cookies für traditionelle serverseitig gerenderte Web-Apps, mit PASETO als moderner Alternative für neue Greenfield-Projekte, die stärkere Defaults wollen.

Häufig gestellte Fragen

Kann ich ein JWT ohne den geheimen Schlüssel dekodieren?

Ja. JWTs sind signiert, aber nicht verschlüsselt, daher können Header und Payload immer gelesen werden. Der geheime Schlüssel wird nur benötigt, um die Signatur zu verifizieren oder ein neues Token zu generieren.

Ist es sicher, Produktions-JWTs hier einzufügen?

Ja. Die gesamte Verarbeitung erfolgt lokal in Ihrem Browser. Ihre Tokens und geheimen Schlüssel werden niemals an einen Server gesendet oder irgendwo gespeichert.

Was ist der Unterschied zwischen HS256, RS256 und ES256?

HS256 verwendet einen gemeinsamen geheimen Schlüssel (HMAC-SHA256). RS256 verwendet RSA-Schlüsselpaare, ES256 verwendet Elliptische-Kurven-Kryptografie. Dieses Tool unterstützt HS256, das am häufigsten für Web-APIs verwendet wird.