JWT-Sicherheitslücken entstehen selten, weil Base64URL falsch verstanden wurde. Kritisch wird die Grenze zwischen einem syntaktisch gültigen Token und einem für diesen Request vertrauenswürdigen Token. Eine Signatur kann mathematisch korrekt sein, während Algorithmus, Issuer, Audience oder Schlüssel nicht zum Anwendungskontext passen. Sichere Implementierungen behandeln Verifikation als feste Policy und nicht als Versuch, möglichst viele Tokenvarianten zu akzeptieren.

Der Tokenheader darf nicht die Sicherheitsregeln bestimmen

Der Header nennt einen Algorithmus, doch die Anwendung muss bereits wissen, welcher Algorithmus für diesen Issuer erlaubt ist. Historische Angriffe nutzten alg: none oder Verwechslungen zwischen asymmetrischen und symmetrischen Verfahren. Eine flexible Bibliothek wurde dadurch mit einem Schlüssel in einer unerwarteten Rolle verwendet.

Für jeden Token-Typ sollte es eine enge Algorithmus-Allowlist geben. Ein unerwarteter Wert führt zur Ablehnung, nicht zu einem Fallback. Bibliotheksupdates und Tests müssen diese Policy erhalten.

Signaturprüfung ohne Claim-Prüfung ist unvollständig

Nach erfolgreicher kryptografischer Verifikation müssen mindestens Ablaufzeit, erwarteter Issuer und Audience geprüft werden, sofern sie Teil des Vertrags sind. nbf und zulässiger Clock-Skew gehören ebenfalls zur Policy. Ein Token eines bekannten Identity Providers kann für eine andere Anwendung ausgestellt sein.

Mandant, Tokenart und Berechtigungsumfang dürfen nicht nur aus beliebigen Custom Claims übernommen werden. Der Verifier muss wissen, welche Claims der konkrete Issuer verlässlich ausstellt und welche Werte für den Endpoint erlaubt sind.

Ein schwaches HMAC-Geheimnis lässt sich offline erraten

Wer ein HMAC-signiertes Token kennt, besitzt Nachricht und Signatur und kann Kandidaten für das Secret lokal testen. Ein menschenlesbares Passwort oder kurzer Konfigurationswert ist deshalb ungeeignet. Das Geheimnis muss kryptografisch zufällig, ausreichend lang und über einen Secret Manager verteilt sein.

Asymmetrische Signaturen reduzieren die Verteilung privater Schlüssel. API-Dienste erhalten nur Public Keys und können keine eigenen gültigen Tokens erzeugen. Das verbessert die Trennung, ersetzt aber keine sichere Verwaltung des privaten Schlüssels beim Issuer.

Ungeprüfte Schlüssel-URLs schaffen SSRF und Vertrauenswechsel

JWT-Header können Felder für Schlüsselreferenzen oder Zertifikate enthalten. Ein Verifier darf nicht beliebige URLs aus einem Token abrufen. Sonst kontrolliert der Angreifer möglicherweise Netzwerkziel und Schlüsselmaterial. Er könnte interne Dienste erreichen oder seinen eigenen Schlüssel als vertrauenswürdig präsentieren.

Schlüsselquellen werden pro Issuer vorkonfiguriert. Netzwerkzugriff erfolgt nur zu erlaubten HTTPS-Zielen, mit Caching, Größenlimits und kontrollierter Rotation. Ein kid wählt ausschließlich innerhalb dieses bekannten Sets.

Key IDs sind untrusted Input

Ein kid darf nicht ungefiltert in SQL, Dateipfade oder Shellbefehle gelangen. Der Wert ist Teil eines vom Angreifer gelieferten Tokens, selbst wenn die Signatur noch nicht geprüft wurde. Die sichere Verwendung ist ein exakter Lookup in einer Map bekannter Schlüssel.

Bei einem unbekannten Identifier kann der Dienst einmal kontrolliert sein konfiguriertes Key Set aktualisieren. Unbegrenzte Refreshes pro Request würden eine einfache Denial-of-Service-Möglichkeit schaffen.

Zu lange Access Tokens erschweren Vorfälle

Ein gestohlenes Bearer Token kann von jedem verwendet werden, der es besitzt. Ohne Senderbindung hilft kein Passwortwechsel unmittelbar. Lange Laufzeiten vergrößern das Zeitfenster für Missbrauch und machen Rollenänderungen langsam sichtbar.

Kurze Access Tokens reduzieren das Fenster. Refresh Tokens benötigen stärkeren Schutz, Rotation und Wiederverwendungserkennung. Bei einem Replay kann die gesamte Tokenfamilie widerrufen und eine erneute Anmeldung verlangt werden.

Logout muss technisch definiert sein

Das Löschen eines Tokens im Browser beendet nur diese lokale Kopie. Andere Geräte oder ein Angreifer können ihre Kopie weiterverwenden. Wenn das Produkt einen globalen Logout verspricht, braucht der Server einen Mechanismus, der dieses Versprechen erfüllt.

Möglichkeiten sind kurze Ablaufzeiten, eine Session- oder Tokenversion im Backend und gezielte Revocation. Jede Variante hat Kosten bei Datenbankzugriff, Cache und Fehlertoleranz. Entscheidend ist, dass die Benutzeroberfläche keine stärkere Wirkung behauptet als das System besitzt.

Sensible Claims sind trotz Signatur sichtbar

Ein gewöhnliches signiertes JWT ist nicht verschlüsselt. Namen, E-Mail-Adressen, interne Rollen oder andere personenbezogene Daten können in Logs, Browsertools und Monitoring auftauchen. Selbst verschlüsselte Tokens können Metadaten im Header offenlegen und benötigen einen sinnvollen Zweck.

Minimalistische Claims reduzieren Datenschutz- und Staleness-Probleme. Ein undurchsichtiger Session-Identifier ist oft geeigneter, wenn der Server den aktuellen Zustand ohnehin laden muss.

Tokens in URLs verbreiten sich unkontrolliert

Queryparameter erscheinen in History, Server- und Proxylogs, Analytics und möglicherweise Referrer-Headern. Ein Bearer Token gehört in einen Authorization-Header oder einen passend geschützten Cookie. Ein einmaliger Link-Token sollte eng begrenzt und nach Nutzung entfernt werden.

Logging-Pipelines müssen Header und Cookies redigieren. Ein Vorfall entsteht nicht nur durch aktiven Angriff; eine Supportaufnahme oder Fehlermeldung kann sonst eine gültige Zugangsdatenfolge enthalten.

Browserstorage verändert das Bedrohungsmodell

Local Storage ist für JavaScript zugänglich. Bei XSS kann ein Angreifer Tokens auslesen und außerhalb des Browsers verwenden. HttpOnly-Cookies schützen vor direktem Auslesen, werden aber automatisch gesendet und benötigen SameSite, CSRF-Strategie und enge Domain- und Path-Attribute.

Die Wahl muss mit der Architektur der Anwendung übereinstimmen. Ein Backend-for-Frontend kann Tokens serverseitig halten und dem Browser nur eine normale Sitzung geben. Das reduziert die Menge kryptografischer Credentials im Client.

Autorisierung darf nicht bei einer Rolle stehen bleiben

Ein Claim wie admin: true ersetzt keine Objekt- und Tenantprüfung. Der Endpoint muss weiterhin entscheiden, ob das Subjekt genau diese Aktion an dieser Ressource ausführen darf. Sonst wird ein global klingender Claim an Stellen verwendet, für die er nie gedacht war.

Hochkritische Entscheidungen sollten aktuelle Daten einbeziehen. Claims eignen sich gut für stabile, grobe Eigenschaften, nicht zwingend für jede dynamische Geschäftsregel.

Fehlermeldungen und Telemetrie müssen Tokens schützen

Bei Verifikationsfehlern sollte die externe Antwort keine Schlüssel- oder Parserdetails offenlegen. Intern helfen Grundkategorien wie abgelaufen, falsche Audience oder unbekannter Key ID. Das vollständige Token muss dafür nicht gespeichert werden.

Ein Hash oder eine sichere Token-ID kann Ereignisse korrelieren. Metriken über Fehlertypen zeigen Clock-Probleme, fehlerhafte Clients und Angriffsversuche, ohne Credentials in Dashboards zu kopieren.

Negative Tests sind entscheidend

Eine Suite sollte Tokens mit falschem Issuer, falscher Audience, abgelaufener und zukünftiger Zeit, unerwartetem Algorithmus, verändertem Payload und unbekanntem Schlüssel enthalten. Tests müssen auch Rotation und gemischte alte und neue Schlüssel abdecken.

Sicherheit entsteht, wenn nur der enge vorgesehene Pfad akzeptiert wird. Ein JWT-Verifier ist kein universeller Tokenleser, sondern eine konkrete Vertrauensentscheidung für einen Issuer, einen Empfänger und einen Zweck.