JWT-Encoder: JSON Web Tokens für die Authentifizierung erstellen und signieren

Was ist ein JWT?

Ein JSON Web Token (JWT) ist ein kompaktes, URL-sicheres Token-Format zur sicheren Übertragung von Informationen zwischen Parteien als JSON-Objekt. Ein JWT besteht aus drei durch Punkte getrennten, Base64URL-kodierten Teilen: header.payload.signature. Der Header gibt den Signatur-Algorithmus an, die Payload enthält die Claims (Daten) und die Signatur bestätigt, dass das Token nicht manipuliert wurde.

JWTs ermöglichen zustandslose Authentifizierung – der Server muss keine Sitzungsdaten speichern, da alle notwendigen Informationen im Token selbst eingebettet sind. Das macht JWTs ideal für verteilte Systeme, Microservices und APIs, bei denen die Sitzungsspeicherung zusätzliche Komplexität und Latenz bedeuten würde.

Die JWT-Struktur erklärt

Jedes JWT setzt sich aus drei eigenständigen Teilen zusammen, die jeweils einen bestimmten Zweck im Lebenszyklus des Tokens erfüllen:

• Header – ein JSON-Objekt, das den Token-Typ (typ: JWT) und den Signatur-Algorithmus (alg: HS256, RS256 usw.) angibt und anschließend Base64URL-kodiert wird
• Payload – ein JSON-Objekt mit Claims wie iss (Aussteller), sub (Subjekt), exp (Ablaufzeit), iat (ausgestellt am) und beliebigen benutzerdefinierten Daten, die Sie übertragen möchten
• Signatur – erzeugt durch Signieren des kodierten Headers und der Payload mit einem geheimen Schlüssel (HMAC) oder einem privaten Schlüssel (RSA/ECDSA), was die Integrität des Tokens sicherstellt

Die Payload ist nicht verschlüsselt – jeder kann sie dekodieren und lesen. Speichern Sie niemals sensible Informationen wie Passwörter oder Kreditkartennummern in einer JWT-Payload. Die Signatur garantiert nur, dass die Daten nicht verändert wurden, nicht dass sie verborgen sind.

Signatur-Algorithmen

Die Wahl des Signatur-Algorithmus bestimmt, wie die JWT-Signatur erzeugt und verifiziert wird. Es gibt drei Hauptfamilien von Algorithmen:

• HMAC (HS256, HS384, HS512) – symmetrische Algorithmen, die denselben geheimen Schlüssel für Signierung und Verifizierung verwenden. Einfach zu implementieren, ideal für Einzelserver-Setups, bei denen Aussteller und Prüfer dasselbe Geheimnis teilen
• RSA (RS256, RS384, RS512) – asymmetrische Algorithmen, die einen privaten Schlüssel zum Signieren und einen öffentlichen Schlüssel zum Verifizieren verwenden. Ideal für verteilte Systeme, in denen mehrere Dienste Tokens verifizieren müssen, ohne Zugriff auf den Signierschlüssel zu haben
• ECDSA (ES256, ES384, ES512) – asymmetrische Algorithmen auf Basis der Elliptische-Kurven-Kryptografie. Sie bieten dieselbe Sicherheit wie RSA bei deutlich kleineren Schlüsselgrößen und schnellerer Berechnung, was sie für Mobil- und IoT-Anwendungen gut geeignet macht

Für die meisten Webanwendungen ist HS256 ausreichend, wenn Token-Aussteller und -Verbraucher derselbe Server sind. Wählen Sie RS256 oder ES256, wenn Tokens von Dritten oder über verschiedene Dienste hinweg verifiziert werden müssen.

Kodieren vs. Dekodieren

Ein JWT zu kodieren bedeutet, ein neues Token zu erstellen, indem Header und Payload zusammengesetzt und die Signatur mit Ihrem geheimen oder privaten Schlüssel erzeugt wird. Das geschieht in der Regel serverseitig beim Login oder beim Token-Refresh. Der resultierende Token-String wird an den Client gesendet, für nachfolgende authentifizierte Anfragen.

Ein JWT zu dekodieren kann zweierlei bedeuten: die Payload-Claims ohne Verifizierung der Signatur extrahieren (nützlich, um Token-Metadaten auf dem Client zu lesen) oder die Signatur vollständig verifizieren, um zu bestätigen, dass das Token authentisch und unverändert ist. Produktivsysteme sollten die Signatur immer verifizieren, bevor sie Claims in der Payload vertrauen.

Häufige Anwendungsfälle

JWTs haben sich als Standard für moderne Authentifizierungs- und Autorisierungsmuster in Web- und Mobilanwendungen etabliert:

• API-Authentifizierung – Clients senden das JWT im Authorization-Header (Bearer-Token) mit jeder Anfrage, sodass der Server die Identität ohne Datenbankabfragen verifizieren kann
• OAuth-2.0-Access-Tokens – OAuth-Anbieter stellen JWTs als Access-Tokens aus, die Informationen zu Scope und Berechtigungen für autorisierten API-Zugriff enthalten
• Microservice-Kommunikation – Dienste geben JWTs untereinander weiter, um Benutzeridentität und Berechtigungen über Dienstgrenzen hinweg ohne zentrale Sitzungsspeicherung weiterzureichen
• Single Sign-On (SSO) – ein zentraler Identitätsanbieter stellt ein JWT aus, das mehrere Anwendungen akzeptieren, sodass sich Benutzer einmal authentifizieren und auf alle verbundenen Dienste zugreifen können

Sicherheits-Best-Practices

JWTs sind leistungsstark, erfordern aber eine sorgfältige Implementierung, um verbreitete Sicherheitsfallen zu vermeiden:

• Kurze Ablaufzeiten setzen – verwenden Sie exp-Claims von 15 Minuten bis 1 Stunde für Access-Tokens und implementieren Sie eine Rotation der Refresh-Tokens für längere Sitzungen
• Niemals sensible Daten in der Payload speichern – JWT-Payloads sind nur Base64URL-kodiert, nicht verschlüsselt. Wer das Token besitzt, kann die Claims lesen
• Immer alle Claims validieren – prüfen Sie exp, iss, aud und alle benutzerdefinierten Claims bei jeder Anfrage. Vertrauen Sie der Payload nicht ohne vollständige Signaturprüfung
• Ausschließlich HTTPS verwenden – übertragen Sie JWTs nur über verschlüsselte Verbindungen, um das Abfangen von Tokens durch Man-in-the-Middle-Angriffe zu verhindern
• Den Algorithmus "none" ablehnen – validieren Sie stets, dass der alg-Header Ihrem erwarteten Algorithmus entspricht. Der Algorithmus "none" umgeht die Signaturprüfung vollständig

Häufig gestellte Fragen

Was ist der Unterschied zwischen JWT und Session-Cookies?

Session-Cookies speichern eine Session-ID auf dem Client, während die eigentlichen Sitzungsdaten auf dem Server liegen. JWTs sind eigenständig – alle Daten stecken im Token selbst. Das macht JWTs zustandslos und horizontal leichter skalierbar, aber schwerer zu widerrufen, da man nicht einfach eine serverseitige Sitzung löschen kann. Session-Cookies sind einfacher für klassische Webanwendungen; JWTs sind besser für APIs und verteilte Systeme.

Wie widerrufe ich ein JWT, bevor es abläuft?

Da JWTs zustandslos sind, gibt es keinen integrierten Widerrufsmechanismus. Gängige Strategien sind: das Führen einer Token-Sperrliste (die bei jeder Anfrage geprüft wird), die Verwendung kurzlebiger Access-Tokens mit Rotation der Refresh-Tokens (der Widerruf des Refresh-Tokens macht künftigen Zugriff ungültig) oder das Speichern einer Token-Version im Benutzerdatensatz, die beim Logout hochgezählt wird.

Gibt es eine Größenbeschränkung für JWTs?

Die JWT-Spezifikation kennt keine formale Größenbeschränkung, doch praktische Grenzen bestehen. Die meisten HTTP-Server begrenzen die Header-Größe auf 8 KB. Da JWTs typischerweise im Authorization-Header gesendet werden, empfiehlt es sich, Tokens unter 4 KB zu halten. Große Payloads mit vielen Claims können diese Grenze überschreiten – erwägen Sie, nur essenzielle Claims im JWT zu speichern und zusätzliche Daten über eine API abzurufen.