Zusammenfassung

  • RFC 9701 liefert einem authentisierten Resource Server eine signierte und optional verschlüsselte JWT-Introspektionsantwort mit iss, aud, iat und einem getrennten token_introspection-Objekt.
  • Der belastbare Nachweis verbindet Anruferidentität, Typ, Schlüssel und Algorithmus, Signatur und Entschlüsselung, Ziel und Frische, internen Tokenzustand, Offenlegung, Replay-Prüfung, lokale Autorisierung und ausgeführte Wirkung.

Der Discovery-Endpunkt listet RS256. Der Client-Eintrag enthält einen jwks_uri. Der JWT-Header nennt einen kid. Keine dieser drei Angaben beweist allein, welcher Schlüssel im Moment der Entscheidung vertraut war oder ob das Objekt überhaupt als Introspektionsantwort geprüft wurde.

RFC 9701 erweitert die Token-Introspektion aus RFC 7662 um eine kryptographisch gesicherte JWT-Antwort. Sie stärkt die Zurechnung zum Authorization Server. Sie ersetzt weder das Access Token noch die lokale Autorisierung des Resource Servers.

Der Anrufer ist Teil der Sicherheitsbehauptung

Der Authorization Server muss den Resource Server identifizieren, authentisieren und autorisieren. Er bestimmt, ob dieser Server Audience des Tokens ist und welche Daten er erhalten darf. Ein anonymer Introspektionsaufruf ist nicht zulässig.

Eine mögliche Verwaltung behandelt Resource Server über RFC 7591 als Clients mit eigener Authentisierung und eigenem Schlüsselmaterial. Die Spezifikation schreibt keine zentrale Produktarchitektur vor, aber sie verlangt begrenzte Credentials und empfängerbezogene Freigabe.

Ist das Token ungültig, abgelaufen, widerrufen oder nicht für den Anrufer bestimmt, enthält die innere Antwort nur active:false. Bei positivem Zustand soll der Scope auf den Resource Server zugeschnitten werden. Personenbezogene Claims benötigen zusätzlich eine empfängerbezogene Policy und Rechtsgrundlage.

Gleichnamige Claims gehören zu verschiedenen Objekten

Der Request setzt Accept: application/token-introspection+jwt. Response und JWT-Header tragen den zugehörigen Medientyp beziehungsweise typ. Oben stehen iss, aud, iat und token_introspection.

Das äußere aud benennt den Empfänger der Antwort. Ein inneres aud benennt die Zielressource des Tokens. Das äußere iat datiert die Aussage, während interne Zeiten zum Token gehören. Wer das Objekt flach abbildet, kann korrekt vergleichen und trotzdem die falsche Behauptung prüfen.

RFC 9701 rät von sub und exp auf oberster Ebene ab und erklärt ausdrücklich, dass die Antwort keine andere Darstellung des Access Tokens ist. Die IANA-Register für OAuth, JWT Claims und den Medientyp koordinieren Namen, nicht die korrekte Schicht im Programm.

Algorithmusangebot, Auswahl und Prüfung sind drei Zustände

Die Antwort ist signiert oder als Nested JWT zuerst signiert und dann verschlüsselt. JWS, JWE und JWT definieren die Formate. Lokale Konfiguration definiert vertrauenswürdige Issuer, Schlüssel, Algorithmen und Altersgrenzen.

RFC 9701 registriert Metadaten für Signatur-, Key-Encryption- und Content-Encryption-Algorithmen. Unterstützte Werte können über RFC 8414 veröffentlicht werden. Ein Eintrag beweist Unterstützung, nicht die Nutzung. Ein kid beweist Auffindbarkeit, nicht issuergebundene Autorisierung.

Die Prüferspur muss Response-Hash, typ, erwarteten Issuer, Key-Set-Version, Algorithmuspolicy, alg, kid, Signaturergebnis sowie bei JWE Empfängerschlüssel und Entschlüsselung erfassen. Erst diese Kombination macht Konfigurationsdrift sichtbar.

Cross-JWT Confusion ist gültige Kryptographie im falschen Verfahren

JWT-Access-Token und Introspektionsantwort können ähnlich aussehen und vom gleichen Vertrauensbereich signiert sein. Akzeptiert ein Gateway jedes signierte JWT, kann eine Antwort als Token eingesetzt werden. RFC 9701 trennt sie durch typ und das innere Objekt; RFC 8725 verlangt explizite, gegenseitig ausschließende Validierungsprofile.

Erfolgreiche Entschlüsselung ändert den Typ nicht. Auch bindet die Antwortsignatur das zugrunde liegende Token nicht an den Präsentierenden. Replay- und Sender-Constraint-Maßnahmen aus RFC 9700 bleiben erforderlich. Eine authentische Aussage über ein aktives Token ist kein Nachweis, dass dieser Akteur es verwenden darf.

Kryptographische und operative Gültigkeit altern verschieden

Das äußere iat macht das Alter der Antwort messbar. Es legt keine universelle Cache-Dauer fest. Nach Ausstellung können Widerruf, Ablauf, Scope-Änderung oder lokale Risikoregeln eintreten. Die alte Signatur bleibt historisch korrekt und operativ zu alt.

Der Resource Server braucht Frischegrenzen pro Operation. Danach wendet er Objektstatus, Rollen, Betragsgrenzen, zusätzliche Freigaben, Geografie und Proof-of-Possession an. scope=write ist ein Eingang. Ein allow ist eine Entscheidung. Erst eine dauerhafte Änderung ist ein Ergebnis.

Verschlüsselung ersetzt keine Rechtsgrundlage

Introspektion kann personenbezogene Daten transportieren. RFC 9701 verlangt eine Rechtsgrundlage und deren Durchsetzung. JWE schützt vor Lesern ohne Schlüssel, legitimiert aber weder einen falschen Empfänger noch überflüssige Claims. RFC 9325 schützt TLS, nicht die spätere Nutzung.

Der Request verrät dem Authorization Server zudem, wann Client oder Nutzer den Resource Server verwenden. Ist diese Beobachtung untragbar, ist ein anderer Übermittlungsweg nötig. Die Wahl der Introspektion ist damit auch eine Datenschutzentscheidung.

Der vollständige Beleg verbindet Token-Fingerprint und Operation mit Caller, Authentisierung, Endpoint/TLS, Response-Bytes, Typ, Schlüssel, Signatur, Entschlüsselung, äußeren Claims, innerem Zustand, Disclosure-Basis, Replay-Prüfung, Policy-Version und Wirkung.

Lu Hengs Minimum-Initial-Specification-Lehre lässt Format und notwendige Claims gemeinsam, aber Vertrauen, Frische, Datenschutz und Autorisierung lokal sichtbar. Reality Layers trennen Register, Bytes, Signatur, Zustand, Entscheidung und Ergebnis. Running-Code Primacy verlangt die konkrete Prüfer- und Enforcement-Spur statt einer Support-Aussage.

Quellen