Ein JWT zu decodieren ist keine Verifizierung

Ein JSON Web Token, kurz JWT, erscheint meist als drei durch Punkte getrennte Zeichenfolgen. Daraus entsteht leicht ein gefährlicher Schluss: Was ein Browser decodieren kann, müsse vertrauenswürdig sein. Das stimmt nicht. Decodieren zeigt die behauptete Struktur eines Tokens. Verifizieren ist eine Sicherheitsentscheidung eines Systems, das erwarteten Aussteller, Audience, Zeitregel, Algorithmus und Prüfschlüssel kennt. Diese Anleitung verwendet eine absichtlich gefälschte, nicht produktive Probe. Sie enthält kein echtes Konto, kein Geheimnis, keinen privaten Schlüssel und keine verwendbare Zugangsdaten.

Das Problem

RFC 7519 beschreibt die kompakte JWT-Serialisierung mit drei base64url-kodierten Segmenten: Header, Payload und Signatur. Base64url ist Kodierung, keine Verschlüsselung. Jeder Besitzer kann die ersten beiden Segmente lesen, und ein Angreifer kann neue schreiben. Die Payload kann behaupten, ein Subjekt sei Administrator, der Token laufe erst nächstes Jahr ab oder stamme von einem vertraut wirkenden Aussteller. Bis die Verifizierung erfolgreich ist, sind das Aussagen einer nicht vertrauenswürdigen Eingabe.

Diese Trennung ist überall wichtig, wo ein Token Berechtigungen verändert. Ein Diagnosewerkzeug darf lokal decodieren, um Datum oder fehlerhafte Claim-Form zu zeigen. Es darf role, sub oder scope nicht nutzen, um eine Erlaubnis zu erteilen. Eine Oberfläche kann auf einen Ablauf hinweisen, doch eine API muss selbst entscheiden und darf die Browser-Interpretation nicht übernehmen. Ein signierter Token kann für eine Anwendung gültig und für eine andere ungeeignet sein, wenn die vorgesehene Audience abweicht.

Verifizierung bedeutet nicht nur, drei Teile zu zählen. Der Verifizierer beginnt mit einer konfigurierten Vertrauensbeziehung: Er akzeptiert wenige Algorithmen, bezieht einen Schlüssel kontrolliert, prüft die Signatur über die ursprünglichen geschützten Daten und bewertet Claims nach lokaler Regel. RFC 8725 warnt davor, angreifergesteuerten Inhalt kritisches Validierungsverhalten wählen zu lassen. Ein Decoder besitzt diesen Kontext nicht.

Praktisches Beispiel

Dies ist ein syntaktisch gültiger Demonstrationstoken. Sein Header decodiert zu {"alg":"HS256","typ":"JWT"}. Seine Payload decodiert zu {"sub":"demo-user","role":"admin","exp":1893456000,"iss":"https://issuer.example.invalid","aud":"demo-api"}. Das dritte Segment ist nur der base64url-Text für das Wort „signature“; es wurde nicht mit einem Geheimnis berechnet und beweist nichts. Die Fälschung ist beabsichtigt.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJkZW1vLXVzZXIiLCJyb2xlIjoiYWRtaW4iLCJleHAiOjE4OTM0NTYwMDAsImlzcyI6Imh0dHBzOi8vaXNzdWVyLmV4YW1wbGUuaW52YWxpZCIsImF1ZCI6ImRlbW8tYXBpIn0.c2lnbmF0dXJl

Ein Decoder kann den Text an Punkten teilen, die ersten zwei Segmente base64url-decoden und Felder zeigen. exp ist eine NumericDate, Sekunden seit der Unix-Epoche, und lässt sich zur Inspektion in ein Datum umwandeln. iss ist der behauptete Aussteller; aud benennt den vorgesehenen Empfänger. Plausible Werte beweisen weder, dass der Aussteller sie erzeugt hat, noch dass die aktuelle API Empfänger ist oder der Token jetzt angenommen werden darf.

Wird demo-user durch ein anderes Subjekt ersetzt oder role von viewer auf admin geändert und die Payload erneut kodiert, bestehen weiterhin drei wohlgeformte Segmente. Auch die Decodierung funktioniert. Ein korrekter Verifizierer lehnt den Text ab, weil die Signatur nicht mehr zu Header und Payload unter dem erwarteten Schlüssel passt. Das Beispiel macht den Punkt sichtbar: Formatanalyse funktioniert, bevor Vertrauen entstanden ist.

Vorgehensweise

Behandeln Sie einen Token als sensible Betriebsdaten, auch wenn er kein Passwort ist. Fügen Sie keinen Produktions-Bearer-Token in eine nicht genehmigte Website, ein Ticket, einen Chat oder Screenshot ein. Verwenden Sie für lokale Diagnose einen kontrollierten Entwicklungstoken, schwärzen Sie Kennungen oder untersuchen Sie ihn in der Umgebung, die ihn ausgestellt hat. Bewahren Sie nur die Fakten auf, die zur Reproduktion nötig sind, etwa Claim-Namen, -Typen und eine Ablaufumrechnung.

Für die Inspektion prüfen Sie zuerst, ob die kompakte Form genau drei nicht leere Segmente hat. Decodieren Sie Header und Payload als UTF-8-JSON, ohne ihnen Autorität zu geben. Notieren Sie alg, lassen Sie es aber nicht die Serverregel auswählen. Prüfen Sie das Zahlenformat von exp, nbf und iat, vergleichen Sie iss mit dem erwarteten Aussteller und aud mit der Kennung der empfangenden Ressource. Das sind Diagnosebeobachtungen, kein positives Prüfergebnis.

Für Authentisierung oder Autorisierung übergeben Sie den originalen kompakten Token an einen vertrauenswürdigen Verifizierer. Dieser braucht eine explizite Liste zulässiger Algorithmen und Schlüsseltypen, einen konfigurierten Aussteller und eine konfigurierte Audience. Er prüft die Signatur, bevor er Payload-Claims verwendet, verwirft abgelaufene Tokens nach seiner Uhrregel und wendet bei Bedarf nbf, Tokentyp, Subjekt oder anwendungsspezifische Berechtigung an. Auch Schlüsselfindung muss authentisiert und auf den bekannten Aussteller begrenzt sein; ein untrusted Header darf keinen beliebigen Schlüsselort vorgeben.

Trennen Sie danach Identitätsvalidierung und Anwendungsautorisierung. Ein verifizierter Token kann zeigen, wer eine Aussage ausgestellt hat; die Anwendung entscheidet trotzdem, ob dieses Subjekt die Aktion ausführen darf. Wenden Sie Least Privilege, Serverregeln und ressourcenspezifische Prüfungen nach der Verifizierung an. Protokollieren Sie Ergebnisse ohne vollständige Bearer-Tokens. Antworten Sie bei Fehlern allgemein und halten Sie genaue Diagnosen nur in geschützten Betriebslogs.

Technische Erklärung

Die Signatur wird über den kodierten Header und die kodierte Payload berechnet, nicht über ein JSON-Objekt, nachdem ein Decoder es formatiert hat. Dadurch akzeptiert ein Verifizierer nicht stillschweigend veränderte Leerzeichen, umsortierte Felder oder ersetzte Segmente. Bei symmetrischen Algorithmen teilen Aussteller und Verifizierer ein Geheimnis; bei asymmetrischen signiert der Aussteller mit privatem Schlüssel und der Verifizierer nutzt einen authentisierten öffentlichen Schlüssel. Eine Payload lesen zu können, verleiht keine Signaturbefugnis.

Claims sind kontextabhängig. RFC 7519 definiert registrierte Namen, überlässt die Regel aber dem Empfänger. exp zeigt einen Zeitpunkt, nach dem der Token nicht mehr akzeptiert werden soll, doch das System bestimmt die erlaubte Uhrabweichung. nbf markiert den Start. iss verlangt einen exakten Vergleich mit einer konfigurierten Kennung, keine optische Ähnlichkeit. aud kann Text oder Liste sein, und eine API muss sich selbst als Empfänger verlangen. Ein Claim kann syntaktisch korrekt und für die aktuelle Anfrage dennoch falsch sein.

Algorithmusverwirrung erklärt, warum konfiguriert und nicht geraten wird. Ein Dienst, der jedes angekündigte alg übernimmt, kann einen ungeeigneten Prüfpfad benutzen. Mischt er Aussteller, ohne Schlüssel, Audiences und Algorithmen zu binden, kann er einen Token aus einer anderen Sicherheitsdomäne akzeptieren. RFC 8725 empfiehlt gegenseitig ausschließende Regeln für verschiedene JWT-Profile und strikte Algorithmusprüfung. Das sind Serveraufgaben, die ein generischer Decoder nicht kennt.

Häufige Fehler

Ein häufiger Fehler ist, eine decodierte Payload als Sitzung zu behandeln. Ein Client liest role: admin und zeigt eine privilegierte Route, bevor das Backend den Token geprüft hat. Einen Button zu verstecken autorisiert nicht, kann aber verwirren und Verhalten preisgeben. Jede geschützte Operation muss auf der vertrauenswürdigen Seite autorisiert werden. Ein weiterer Fehler ist, exp nur wegen eines Zukunftsdatums zu akzeptieren: Ein zukünftiges Datum repariert keine ungültige Signatur, keinen falschen Aussteller, keine falsche Audience und keinen falschen Typ.

Ebenso falsch ist das Protokollieren vollständiger Tokens bei einer Decodierungsdiagnose. Bearer-Tokens können bis zum Ablauf Zugriff geben; Logs, Analytik, Fehlerberichte und Erweiterungen werden dann unnötige Expositionsorte. Schwärzen Sie sie und kopieren Sie sie nicht in Beispiele. Ein öffentlicher Decoder kann beim Format helfen, kennt aber keine privaten Schlüssel, zugelassenen Aussteller, Widerrufsregel oder die genaue empfangende API.

Schalten Sie die Signaturprüfung nicht ab, damit Tests funktionieren. Erstellen Sie getrennten Testaussteller und Testschlüssel mit kurzer Laufzeit und begrenzten Rechten. Lehnen Sie unsignierte Tokens ab, außer ein sorgfältig entworfenes, nicht authentisierendes Format verlangt sie. Eine Bibliothek darf keinen Downgrade akzeptieren, weil ein Header ihn fordert. Testen Sie manipulierte Signaturen, unerwartete Audiences, alte Zeiten und falsche Aussteller genauso bewusst wie den Erfolgsfall.

Wichtige Überlegungen

Definieren Sie Token-Grenzen vor der Bibliothekswahl. Dokumentieren Sie, wer ausstellt, welche Dienste prüfen, welche Audiences bestehen und wie Schlüssel rotieren. Verwenden Sie verschiedene Audiences für APIs mit verschiedenen Rechten. Konfigurieren Sie die Aussteller-URI exakt und validieren Sie sie einheitlich. Bei mehreren Profilen erhält jedes eine eigene Regel statt einer freizügigen Regel, die den Zweck aus optionalen Claims errät.

Zeit braucht Betriebssorgfalt. Synchronisieren Sie Serveruhren, bestimmen Sie eine kleine dokumentierte Toleranz und beobachten Sie Fehler, die auf Drift hinweisen. Wählen Sie Access-Token-Laufzeiten passend zum Risiko und planen Sie Erneuerung oder Widerruf außerhalb des Decoders. Eine lokale Anzeige von exp kann einen Fehler erklären; nur die Zeitregel des Verifizierers entscheidet Annahme. Nehmen Sie nicht an, ein Token sei gültig, weil ein Datum in einer anderen Zeitzone aktuell aussieht.

Vermeiden Sie unnötige decodierte Daten im Client-State. Eine Oberfläche kann nicht sensible Darstellung brauchen, doch der Server muss Autorität für Rechte und geschützte Ressourcen bleiben. Speichert ein Browser Bearer-Tokens, hängt die Exposition vom Bedrohungsmodell und Speicher ab; Decodieren verringert sie nicht. Bei der Gestaltung einer Identitätsgrenze gehört eine Sicherheitsprüfung dazu.

Grenzen

Diese Anleitung erklärt die konzeptionelle Grenze zwischen Decodieren und Verifizieren. Sie liefert keine fertige Authentisierungskonfiguration, kein Schlüsselmanagement und keine Garantie, dass eine JWT-Bibliothek bei Fehlkonfiguration sicher ist. APIs, Schlüsselverteilung, Tokenprofile, Browserspeicher und Vorfallanforderungen unterscheiden sich je System. Lesen Sie aktuelle Dokumentation des eingesetzten Verifizierers und testen Sie ihn mit realen Aussteller- und Audience-Einstellungen.

JWTs sind nicht für jede Sitzung oder API erforderlich. Opake Tokens, serverseitige Sitzungen und andere Verfahren haben andere Abwägungen. Eine gültige Signatur beweist auch nicht, dass ein Benutzer jetzt jede Aktion ausführen darf, ein Gerät unversehrt ist oder ein Token nicht durch ein anderes System widerrufen wurde. Verifizierung ist ein notwendiges Steuerelement in einem größeren Entwurf.

Checkliste

Behalten Sie vor dem Vertrauen in ein JWT den originalen kompakten Token und trennen Sie Inspektion von Autorisierung. Decodieren Sie Header und Payload nur zur Strukturdiagnose; sichtbare Claims sind kein Beweis. Verifizieren Sie die Signatur in einem vertrauenswürdigen System mit Algorithmus-Allowlist und authentisierter Schlüsselquelle. Fordern Sie erwarteten Aussteller und Audience, bewerten Sie Ablauf und Not-before mit dokumentierter Zeitregel und autorisieren Sie anschließend auf dem Server. Veröffentlichen oder protokollieren Sie nie echte Bearer-Tokens, deaktivieren Sie Prüfung nie aus Bequemlichkeit und testen Sie veränderte Signaturen und Claims als Negativfälle. Nutzen Sie RFC 7519 und RFC 8725 zusammen mit aktueller Bibliotheksdokumentation.