Was ist ein JWT? Aufbau, Prüfung und häufige Fehler

Ein JSON Web Token (JWT) ist ein kompaktes Format zum Übertragen von Aussagen zwischen Systemen. Es wird häufig für Authentifizierung und Autorisierung verwendet, bildet aber allein kein vollständiges Anmeldesystem. Anwendungen benötigen weiterhin Sitzungsverwaltung, Berechtigungen, Schlüsselrotation, Widerruf und Kontowiederherstellung.

Die drei Segmente

Ein signiertes JWT besteht meist aus drei durch Punkte getrennten Teilen: header.payload.signature. Der Header nennt Typ und Algorithmus, der Payload enthält Claims und die Signatur macht Änderungen erkennbar. Header und Payload sind Base64url-kodiert und für jeden lesbar.

Teil	Aufgabe	Geheim?
Header	Algorithmus und Metadaten	Nein
Payload	Claims wie Aussteller, Subjekt und Zeiten	Nein
Signatur	Integritätsprüfung mit einem Schlüssel	Gibt den Schlüssel nicht preis

Dekodieren ist keine Verifikation

Ein Decoder zeigt Header und Payload ohne Schlüssel an. Das hilft bei der Fehlersuche, beweist aber nicht, wer das Token erstellt hat. Der Server muss die Signatur mit einem erlaubten Algorithmus und einem vertrauenswürdigen Schlüssel prüfen, bevor ein Claim Zugriffsrechte beeinflusst.

Vertraue role: admin niemals nur deshalb, weil es im dekodierten Payload steht.

Wichtige Claims

• iss muss einem konfigurierten Aussteller entsprechen.
• aud muss den empfangenden Dienst enthalten.
• exp beendet die Gültigkeit nach dem angegebenen Zeitpunkt.
• nbf verhindert eine Annahme vor diesem Zeitpunkt.
• sub darf nur im Namensraum des geprüften Ausstellers interpretiert werden.

Numerische JWT-Zeiten sind gewöhnlich Unix-Sekunden, nicht Millisekunden. Eine Uhrtoleranz sollte klein und bewusst gewählt sein.

Häufige Implementierungsfehler

• Jeden im fremden Header genannten Algorithmus akzeptieren.
• Die Signatur prüfen, aber Aussteller oder Zielgruppe ignorieren.
• Passwörter, Gesundheitsdaten oder private Informationen im lesbaren Payload ablegen.
• Langlebige Access Tokens ohne Rotation oder Widerruf ausgeben.
• Vollständige Tokens in Logs, Analysen, Tickets oder Screenshots schreiben.

Transport und Speicherung

Übertrage Tokens ausschließlich über HTTPS. Browser-Speicherung hat Abwägungen: JavaScript-lesbarer Speicher vergrößert die Auswirkung von XSS, Cookies benötigen sichere Attribute und ein CSRF-Konzept. Die passende Lösung hängt vom Bedrohungsmodell und den Schutzfunktionen des Frameworks ab.

Sicherer Inspektionsablauf

1. Nach Möglichkeit ein künstliches oder widerrufenes Token verwenden.
2. Lokal dekodieren und nur benötigte Felder untersuchen.
3. Zeitangaben, Aussteller und Zielgruppe prüfen.
4. Das Token in der Anwendung mit ihrer vertrauenswürdigen Schlüsselkonfiguration verifizieren.
5. Token anschließend aus Logs und Bildern entfernen.

Der JWT-Decoder von ToolBlur zeigt die Struktur lokal, validiert jedoch keine Signatur. Der Base64-Konverter erklärt die verwandte Kodierung. Die Formatspezifikation steht in RFC 7519.

Häufige Fragen

Ist ein JWT verschlüsselt?

Normalerweise nicht. Eine Signatur schützt Integrität, der Payload bleibt lesbar.

Kann ein Decoder das Token prüfen?

Nicht ohne Schlüssel und vertrauenswürdige Regeln für Algorithmus, Aussteller und Zielgruppe.

Sollte ich ein echtes Token einfügen?

Nein. Verwende nach Möglichkeit ein künstliches oder bereits widerrufenes Token.