Zusammenfassung

  • Am 24. August 2026 billigte das IESG Revision 10 von draft-ietf-oauth-rfc8725bis als Best Current Practice. Zum Belegstichtag war der Text weiterhin ein Internet-Draft in der Warteschlange des RFC Editor; nach Veröffentlichung soll er RFC 8725 ablösen und RFC 7519 aktualisieren.
  • Der zentrale Betriebsgrundsatz lautet, Prüfregeln für verschiedene JWT-Arten gegenseitig auszuschließen. Eine korrekte Signatur genügt nicht: Typ, Aussteller, Zielgruppe, Claims, geschützte Header, Algorithmus, Schlüssel und Anwendungskontext müssen ebenfalls stimmen.

Ein Sicherheitsereignis am Zugangstor

Ein Unternehmen verarbeitet Security Event Tokens in einem Ereignisempfänger. Eine API im selben Netz akzeptiert Zugriffstoken. Beide vertrauen demselben Aussteller und demselben Schlüsselsatz. Ein ordnungsgemäß signiertes Ereignistoken erreicht die API; die gemeinsame JWT-Bibliothek prüft die Signatur und meldet Erfolg.

Die Kryptografie ist korrekt. Die Autorisierung ist es nicht.

Das ist ein gedachter Grenztest, kein berichteter Vorfall. Er zeigt die Cross-JWT-Confusion, gegen die sich die Überarbeitung richtet: Ein für Zweck A ausgestelltes Objekt wird in einen Kontext für Zweck B eingesetzt. Der Angreifer muss keine Signatur fälschen, wenn der Empfänger aus „dieser Aussteller hat die Aussage gemacht“ fälschlich „diese Aussage darf hier eine Handlung auslösen“ macht.

Ein stärkerer Algorithmus löst das nicht. Ereignisempfänger und Zugangs-API brauchen nicht überlappende Annahmeregeln, selbst wenn Format, Aussteller, Schlüssel und einzelne Claim-Namen identisch sind.

Beschlossen, aber noch nicht als RFC erschienen

Die IESG-Mitteilung datiert die Billigung von „JSON Web Token Best Current Practices“, Revision 10, auf den 24. August um 18:02 UTC. Der Text stammt aus der OAuth Working Group und soll als BCP veröffentlicht werden.

Am 28. August führte der Datatracker ihn noch als aktiven Internet-Draft vom 21. August, zuletzt am 25. August aktualisiert und bis 22. Februar 2027 gültig. Der IESG-Status lautete RFC Ed Queue. Der RFC Editor wartete auf eine noch nicht eingegangene Referenz. IANA sah keine neuen Registermaßnahmen vor, führte den Vorgang aber weiterhin als laufend.

Die Billigung ist damit eine echte Standardisierungsnachricht, aber noch keine RFC-Nummer, keine abgeschlossene Redaktion und kein Nachweis verbreiteter Implementierung. Bei Veröffentlichung wie angekündigt wird der Text RFC 8725 obsolet machen und die JWT-Grundspezifikation RFC 7519 aktualisieren.

Vier Prüfungen statt eines pauschalen „gültig“

JWT ist ein Claim-Format, kein einzelner Sicherheitszustand. Es kann als signiertes JWS, verschlüsseltes JWE, verschachteltes Objekt oder — wenn ausdrücklich zugelassen — als ungesichertes JWT vorliegen. Die kompakte base64url-Punktdarstellung ist zudem nicht mit jeder JOSE-JSON-Serialisierung austauschbar.

Der Empfänger sollte vier Fragen nacheinander beantworten:

  1. Entspricht das Objekt genau der an diesem Endpunkt erlaubten Serialisierung?
  2. Ist Signatur oder authentisierte Verschlüsselung mit einem vorab zugelassenen Algorithmus und dem vorgesehenen Schlüssel gültig?
  3. Gehört das Objekt zu der Tokenart, die dieser Verbraucher verarbeiten soll?
  4. Berechtigen seine Claims jetzt, für diesen Aussteller, diese Zielgruppe und dieses Subjekt, zu der angeforderten Handlung?

Das Entschlüsseln eines JWE verifiziert nicht automatisch die Signatur eines inneren JWT. Erfolgreiches Parsen erzeugt kein Vertrauen. Ein gültiges JWS macht seine Claims nicht in jedem Dienst gültig, der denselben Schlüssel kennt.

typ muss eine Klasse ausschließen können

Wo Verwechslung droht, empfiehlt die Revision explizite Typisierung. Der in RFC 8417 definierte Typ für Security Event Tokens kann die Anwendungsklasse vor der Claim-Auswertung unterscheiden. Der allgemeine Wert JWT wiederholt dagegen nur die Containerfamilie und bezeichnet keinen Anwendungsvertrag.

Der Typ allein genügt nicht. Die Annahmemengen verschiedener Validatoren sollen sich gegenseitig ausschließen. Das lässt sich durch unterschiedliche explizite Typen, Pflicht-Claims oder Werte, geschützte Header, Schlüssel, Zielgruppen oder Aussteller erreichen.

RFC 9068 gibt OAuth-Zugriffstoken ein eigenes JWT-Profil; RFC 8417 tut dies für Sicherheitsereignisse. Beide Objekte können authentisch und korrekt signiert sein, ohne austauschbar zu werden. Der Verbraucher wählt das Profil, bevor er den Claims Autoritätswirkung gibt.

Bei Altbeständen fehlt typ häufig. Eine sofortige Pflicht kann Dienste unterbrechen. Ein kompatibler erster Schritt verwirft jeden vorhandenen, aber falschen Typ, misst fehlende Angaben und führt die Pflicht anschließend koordiniert bei Ausstellern und Verbrauchern ein.

Gemeinsame Verwaltung schafft keine gemeinsame Zielgruppe

iss bezeichnet die behauptende Stelle, aud die vorgesehenen Empfänger. Beide müssen profilgerecht geprüft werden, bevor Claims Routen, Rechte oder Daten beeinflussen.

Dienst A und B bilden nicht automatisch dieselbe Audience, weil sie derselben Firma gehören oder denselben Identitätsdienst nutzen. Ein für A bestimmtes Token wird dadurch nicht zur Berechtigung bei B.

Auch sub besitzt keine universelle Semantik. Es kann eine Person, eine Clientanwendung oder den Gegenstand eines Sicherheitsereignisses bezeichnen. Das Profil liefert die Bedeutung, nicht der Feldname allein.

Das Token bestimmt nicht seine Prüfpolitik

Die Liste zulässiger Algorithmen gehört dem Empfänger. alg ist ein zu prüfender Eingangswert, keine Anweisung, mit der das Token seine eigene Prüfart auswählt. Die Revision bindet außerdem einen Schlüssel an genau einen Algorithmus und verhindert so widersprüchliche Umdeutungen desselben Materials.

Schlüsselauswahl-Header wie kid, jku und x5u können Datenbankabfragen oder externe Abrufe steuern. Ohne enge Regeln entstehen Injektions- oder serverseitige Request-Forgery-Pfade. Vor der Verifikation sind sie Angreifereingaben; danach geben sie dem Aussteller dennoch keinen unbegrenzten Netzzugang.

Die Überarbeitung erfasst auch Mindestaufwand bei passwortbasierter Verschlüsselung, Dekompressionsgrenzen für JWE und vollständig spezifizierte Algorithmuskennungen nach RFC 9864. Damit behandelt sie Ressourcenerschöpfung und Mehrdeutigkeit, nicht nur Fälschungen.

Die Beweiskette einer Entscheidung

Erhaltene Bytes, Serialisierung, Endpunkt, erwartetes Profil, geschützte Header, Algorithmusliste, aufgelöster Schlüssel und sein einziger Algorithmus, kryptografisches Ergebnis, Typ, Aussteller, Zielgruppe, Pflicht-Claims, Zeitfenster, nötiger Replay- oder Widerrufsstatus, Richtlinienentscheidung, angeforderte Handlung und Endwirkung gehören zusammen.

Ein Logeintrag „JWT valid“ löscht genau die Trennlinien, die eine spätere Untersuchung braucht. Er zeigt weder das gewählte Profil noch die geprüfte Audience noch die ausgelöste Wirkung. Der Standard beschreibt das Mindestinvariant; erst ein Substitutionstest am laufenden Verbraucher, dessen Ablehnung und das Ausbleiben einer Folgehandlung beweisen die Grenze.

Quellen