Zusammenfassung

  • RFC 7662 ermöglicht einer geschützten Ressource, den aktuellen Zustand eines Tokens beim Autorisierungsserver abzufragen und für sie relevante Metadaten zu erhalten.
  • active: true ist eine belastbare Aussage über das Token, aber keine Genehmigung des konkreten Vorgangs, kein Ausführungsnachweis und keine dauerhafte Ergebnisquittung.
  • Caching tauscht Last und Latenz gegen Aktualität; Tokenstatus, lokale Zugriffsentscheidung und Anwendungsergebnis brauchen getrennte Belege.

Ein wahres Ergebnis mit begrenztem Zuständigkeitsbereich

Nicht jeder Ressourcenserver kann ein vorgelegtes Zugriffstoken vollständig selbst prüfen. Das Token kann opak sein, sein Widerrufszustand kann an anderer Stelle liegen oder die Ausstellungspolitik kann sich geändert haben. Bei der Introspektion sendet die geschützte Ressource das Token an den Autorisierungsserver. Dessen Antwort muss das boolesche Feld active enthalten und kann Scope, Client, Benutzer, Tokentyp, Zeitgrenzen, Zielgruppe und Aussteller ergänzen.

Das Ergebnis hat Substanz. Nach RFC 7662 wurde ein aktives Token im Allgemeinen von diesem Autorisierungsserver ausgestellt, ist nicht widerrufen und liegt innerhalb seiner Gültigkeitsdauer. Der Server nimmt die anwendbaren Prüfungen vor: Ablauf, frühesten Nutzungszeitpunkt, Widerruf, Signatur und die Frage, ob das Token bei der anfragenden geschützten Ressource eingesetzt werden kann. Wer darin nur einen erfolgreichen HTTP-Aufruf sieht, unterschätzt das Protokoll.

Wer darin bereits die Freigabe der Anwendung sieht, überschätzt es. Der Autorisierungsserver kennt den Lebenszyklus der Berechtigung. Er kennt nicht zwingend den aktuellen Kontostand, den Eigentümer eines Datensatzes, ein Tageslimit, eine Sperrfrist oder die Version des zu ändernden Objekts. Diese Tatsachen gehören zum Ressourcenserver und zur Fachanwendung.

Ein aktives Token mit einem passenden Scope kann daher für eine Anfrage ungeeignet bleiben. Das Objekt kann einem anderen Mandanten gehören, eine stärkere Anmeldung verlangen oder unter einer lokalen Sperre stehen. active macht das Token zu einem zulässigen Beweisstück für die Entscheidung. Es fällt die Entscheidung nicht selbst.

Richers Schnittstelle verbindet zwei Autoritäten

Justin Richer ist als Autor der RFC 7662 genannt, eines IETF-Standards-Track-Dokuments zur OAuth-2.0-Token-Introspektion. Die Zuschreibung sollte weder kleiner noch größer gemacht werden: Der RFC ist ein Ergebnis des IETF-Standardisierungsprozesses. Er verleiht Richer keine persönliche Kontrolle über Implementierungen und macht ihn nicht zum alleinigen Erfinder jeder OAuth-Idee.

Die Spezifikation verbindet zwei Wissensbereiche. Der Autorisierungsserver kann verbindlich über Ausstellung, Gültigkeit, Widerruf und tokenbezogene Attribute sprechen. Die geschützte Ressource kennt Methode, Zielobjekt und lokale Regeln. Indem sie den ersten Server befragt, gibt sie ihre eigene Verantwortung nicht ab.

Schon das OAuth-Rollenmodell wahrt diese Trennung. Der Client legt dem Ressourcenserver ein Zugriffstoken vor. Der Ressourcenserver validiert es und bedient die Anfrage, wenn seine Bedingungen erfüllt sind. RFC 6750 beschreibt diesen Ablauf für Bearer Tokens. Introspektion standardisiert eine Quelle für Validierungsfakten; sie erzeugt nicht die Fachregel, die einen Scope auf eine bestimmte Handlung abbildet.

Ein Audit muss deshalb zwei Urteile festhalten. Welcher Autorisierungsserver erklärte welches Token wann und für welche Ressource für aktiv? Welche Version der lokalen Richtlinie erlaubte oder verweigerte anschließend welche Anfrage? Ein einzelner Eintrag „autorisiert“ spart Felder, aber vernichtet die Trennlinie, die im Störungsfall gebraucht wird.

Wer fragt, bestimmt mit, was sichtbar wird

Eine Introspektionsantwort ist kein universeller Tokenausweis. RFC 7662 erlaubt dem Autorisierungsserver, die Antwort an die anfragende geschützte Ressource anzupassen. Er kann insbesondere nur diejenigen Scopes zurückgeben, die für diesen Empfänger relevant sind. Das begrenzt unnötige Offenlegung und bindet die Aussage an ihren Kontext.

Folglich beweist ein bei Dienst A gespeicherter Befund nicht automatisch, was Dienst B erfahren oder entscheiden durfte. Anfragende Ressource, Zielgruppe, Zeitpunkt und tatsächlich offengelegte Felder gehören zusammen. Unterschiedliche Antworten können beabsichtigt und korrekt sein.

RFC 8707 trennt eine benachbarte Dimension. Ein Resource Indicator beschreibt, wo ein Token eingesetzt werden soll; der Scope beschreibt, welche Art von Zugriff angefordert wird. Einsatzort und Berechtigungsart ergänzen sich. Keines von beiden bestätigt, dass eine einzelne Geschäftshandlung ausgeführt wurde.

Auch optionale Felder sollten nicht umgedeutet werden. exp und nbf setzen Zeitgrenzen. aud und iss helfen bei Zielgruppe und Aussteller. sub, username und client_id können verschiedene Rollen benennen. jti identifiziert das Token. Da ein Token viele Aufrufe begleitet, ist seine Kennung weder Bestellnummer noch Zahlungsreferenz noch Ausführungs-ID.

Der Cache konserviert einen früheren Gegenwartsstand

Eine Introspektion bei jeder Anfrage belastet den Autorisierungsserver und fügt dem kritischen Pfad einen Netzaufruf hinzu. RFC 7662 lässt das Zwischenspeichern der Antwort zu. Sie benennt auch den Preis: Je länger der Cache lebt, desto weniger aktuell ist die Aussage.

Ein Ressourcenserver kann um 10:00 Uhr ein aktives Token feststellen und den Befund fünf Minuten behalten. Um 10:01 Uhr widerruft der Inhaber es nach RFC 7009, oder ein Administrator beendet die zugrunde liegende Gewährung. Bis 10:05 Uhr kann die Ressource weiterhin mit dem alten Zustand arbeiten. Der Autorisierungsserver kennt schon die neue Wahrheit; der Ressourcenserver verwendet das von seiner Konfiguration erlaubte ältere Bild.

Die TTL ist damit eine Sicherheitsentscheidung, nicht nur ein Leistungsparameter. Tokenlebensdauer, zugesagte Widerrufsgeschwindigkeit, Empfindlichkeit der Operation, Verfügbarkeit des Autorisierungsservers und möglicher Schaden einer veralteten Freigabe müssen einfließen. Das Lesen eines öffentlichen Katalogs und das Ändern von Wiederherstellungsdaten verdienen nicht automatisch dasselbe Zeitfenster.

Ein Widerruf korrigiert außerdem nicht die Vergangenheit. RFC 7009 macht das Token und je nach Server verwandte Token oder Gewährungen unbrauchbar. Bereits ausgezahltes Geld, preisgegebene Daten oder versandte Nachrichten holt das Protokoll nicht zurück. Künftige Akzeptanz und die Behebung eingetretener Folgen sind verschiedene Kontrollflächen.

Nach der Zugriffsentscheidung beginnt die Ergebnisfrage

Selbst eine lokal erlaubte Anfrage kann unklar enden. Der Dienst fällt vor dem Commit aus oder speichert erfolgreich und verliert danach die Antwort. Eine Warteschlange nimmt den Auftrag an, während ein Worker ihn später verwirft. Der Client wiederholt den Aufruf mit demselben weiterhin aktiven Token. Zwei gültige Anfragen können dann eine einzige menschliche Absicht doppelt ausführen.

Kein Introspektionsfeld ist dafür eine Quittung. Ein Scope beschreibt eine Zugriffsklasse. jti korreliert Nutzungen eines Tokens. Das erfolgreiche Introspektionsgespräch beweist nur, dass Tokeninformationen geliefert wurden. Es beweist keinen Anwendungszustand.

Folgenreiche APIs brauchen eine dauerhafte Operationsidentität, etwa einen Idempotenzschlüssel, eine Befehls-ID oder eine Versionsbedingung. Nach einem Timeout muss das Ergebnis über diese Identität abfragbar sein. Tokenprüfung, Ressourcenentscheidung, Operations-ID, Commit und Zustellung der Antwort sind miteinander verknüpfbar, aber nicht austauschbar.

Eine genaue Lesart von RFC 7662 macht die Introspektion nicht schwächer. Sie bewahrt die Stärke einer standardisierten Antwort auf eine eng umrissene, schwierige Frage. Erst wenn diese Antwort nicht mehr für ungesehene Entscheidungen sprechen muss, wird die Verantwortung des Gesamtsystems klar.

Quellen