Zusammenfassung

  • „Aktiv“ ist in RFC 9767 eine kontextgebundene Verknüpfung aus Aussteller, Widerruf, Zeit, Nachweis, Zielserver und angefragtem Zugriff.
  • Der Autorisierungsserver bewertet den Tokenzustand. Der Ressourcenserver prüft die aktuelle Präsentation, wendet seine örtliche Richtlinie an und wählt die tatsächliche Antwort.
  • Belastbare Abläufe trennen Introspektionsbefund, Nachrichtenbeweis, lokale Entscheidung und beobachtete Wirkung; Cachealter und abgeleitete Tokens bleiben sichtbar.

Die Frage vor der Antwort

Der Client legt einem Ressourcenserver ein Zugriffstoken vor. Der RS kann dessen Wert beim Autorisierungsserver introspektieren. Dabei spricht er nicht als Stellvertreter des Clients: Er signiert den Aufruf mit seinem eigenen Schlüssel und nennt seine eigene Identität.

Zur Anfrage gehören der Tokenwert, üblicherweise das vom Client verwendete Nachweisverfahren und optional die Mindestberechtigung, die für die anstehende Operation nötig ist. Diese Felder bilden den Geltungsbereich der Antwort. Der AS muss alle angegebenen Parameter berücksichtigen; kann er einen Teil nicht verarbeiten, darf er das Token nicht als aktiv kennzeichnen.

Das ist der Grund, weshalb RFC 9767 mehr leistet als ein Ja/Nein-Endpunkt. Der Kern von GNAP regelt die Grant-Beziehung zwischen Client und AS. Die Erweiterung stellt eine interoperable Verbindung zum RS her, ohne dessen Rolle aufzulösen. Ein gemeinsames Protokoll ist kein gemeinsames Entscheidungsorgan.

Auch die Aufnahme des RS-Schlüssels bleibt eine eigene Vertrauensfrage. Vorregistrierung, ein anderer Zulassungsweg oder Trust on First Use sind denkbar und außerhalb des Standards. Eine gültige Signatur beweist daher Besitz im gewählten Modell, nicht die richtige organisatorische Zuordnung aller Ressourcen.

Sechs Bedingungen hinter „aktiv“

Ein positives Ergebnis bedeutet: Das Token stammt vom antwortenden AS, ist weder widerrufen noch abgelaufen, ist an das genannte Nachweisverfahren gebunden, passt zum identifizierten RS und deckt den angegebenen Zugriff ab, falls ein solcher verlangt wurde.

Ein negatives Ergebnis benennt dagegen nicht die Ursache. False gilt ebenso bei Unbestimmtheit, etwa wenn das Token nicht gefunden wird. Weitere Felder werden dann weggelassen. Wer daraus automatisch „widerrufen“ macht, ersetzt ein geschlossenes Fehlerverhalten durch eine erfundene Diagnose.

Der positive Wert ist genauso eng. Er bestätigt weder den aktuellen Nutzerwillen noch die Harmlosigkeit der Nutzdaten, die Existenz eines Objekts, eine Geschäftsregel, eine Quote oder einen späteren Diensterfolg. Er besagt nur, dass das Token die in dieser Anfrage repräsentierten Prüfungen bestanden hat.

Bei Aktivität kann die Antwort Rechte, Schlüsselmaterial, Flags und Zeitangaben enthalten. Die Rechte dürfen auf den fragenden RS zugeschnitten und sogar leer sein. Der Tokenwert selbst darf nicht zurückgesendet werden. Diese Filterung schützt vor unnötiger Offenlegung und verhindert zugleich, dass eine Antwort als vollständiges Abbild des gesamten Grants gelesen wird.

Die Entscheidung bleibt lokal

Nach der Introspektion schreibt RFC 9767 dem RS ausdrücklich die Wahl der weiteren Handlung zu. Reichen die Rechte nicht, kann er einen Fehler oder eine öffentliche Ressource liefern. Die endgültige Antwort liegt in seinem Ermessen.

Diese Formulierung ist keine Hintertür. Sie ordnet die Verantwortung dem System zu, das die konkrete Ressource kontrolliert. Der AS kennt Grant, Tokenstatus und Aussteller. Der RS kennt Methode, Endpunkt, Objektzustand, örtliche Sicherheitsregeln und die Antworten, die er technisch ausführen kann.

Ermessen muss nachprüfbar sein. Ein Entscheidungsbeleg enthält Ressource und Operation, ausgewertete Rechte, Richtlinienversion, zusätzliche Kontrollen, Softwarestand und gewählte Antwort. Die Ausgabe öffentlicher Daten nach unzureichender Berechtigung ist kein erfolgreicher Zugriff auf geschützte Daten.

Auch die Wirkung darf nicht in den Tokenbefund hineingelesen werden. Ein Schreibvorgang kann bestätigt und die Antwort verloren gehen. Ein nachgelagerter Dienst kann ausfallen. Ein HTTP-Erfolg kann einen Anwendungsfehler umhüllen. Dafür braucht es eigene Commit- und Zustellbelege.

Tokenprüfung und Nachrichtenbeweis

Bei schlüsselgebundenen Tokens sind zwei Prüfungen nötig. Der Token muss gültig und für den Kontext geeignet sein. Außerdem muss die aktuelle Anfrage den erwarteten Schlüsselbeweis tragen. Nur die Signatur zu prüfen wäre gefährlich: Ein kompromittierter Schlüssel oder Confused Deputy könnte formal richtige, aber nicht berechtigte Nachrichten erzeugen.

Umgekehrt ersetzt eine positive Introspektion nicht den Beweis des aktuellen Requests. RFC 9767 verlangt eine unabhängige Prüfung je Nachricht und warnt davor, ein Proof-Ergebnis aus dem Cache auf einen späteren Aufruf zu übertragen. Ziel, Inhalt und Frische können sich ändern.

HTTP Message Signatures, DPoP und mTLS-gebundene Tokens zeigen unterschiedliche Bindungsmodelle. Keines davon entscheidet die Fachlogik. Der Prüfbeleg sollte deshalb bedeckte Nachrichtenkomponenten, Schlüssel, Algorithmus, Nonce oder Zeitbezug und Ergebnis festhalten, getrennt vom Introspektionsbeleg.

Das Cachefenster ist eine Betreiberentscheidung

Introspektion verursacht Netzlatenz und koppelt die Verfügbarkeit des RS an den AS. Ein RS darf Validierungsergebnisse cachen. Der Preis ist ausdrücklich genannt: bessere Leistung gegen weniger Aktualität und Genauigkeit. Ein inzwischen widerrufenes Token kann während eines alten positiven Eintrags weiter angenommen werden.

Damit ist die TTL keine bloße Optimierung. Sie bestimmt, wie lange der RS eine vergangene Aussage des AS an die Stelle des gegenwärtigen Zustands setzt. Unterschiedliche Aktionen können unterschiedliche Toleranzen haben; eine öffentliche Lesefunktion und eine irreversible Zahlung sollten nicht zufällig denselben Bibliotheksstandard erben.

Der Cache-Schlüssel muss den Kontext bewahren. Nur nach Token zu indizieren kann eine Antwort für falschen RS, falsches Proof-Verfahren oder breitere Rechte wiederverwenden. Negative Ergebnisse sind ebenfalls mehrdeutig, weil false neben eindeutigen Ablehnungen auch Unwissen enthält.

RFC 7009 beschreibt den Widerruf am Autorisierungsserver. Das ist noch kein Nachweis, dass jeder RS-Cache invalidiert wurde. RFC 9767 erwähnt proaktive Signale, standardisiert sie aber nicht. Operative Schließung verlangt deshalb Invalidierungsereignis, betroffene Einträge und eine nachfolgende Entscheidung.

Weniger Daten, mehr Beobachtung

Ein RS braucht nicht alle Claims eines Tokens. Die Introspektion kann nur die für ihn relevanten Informationen offenlegen. Das schützt etwa davor, dass ein nichtmedizinischer Dienst eine medizinische Kennung erhält. Gleichzeitig erfährt der AS bei jedem Aufruf, wann ein bestimmtes Token bei welchem RS benutzt wird.

Strukturierte Tokens verschieben diesen Kompromiss. Lokale Prüfung reduziert die Echtzeitbeobachtung durch den AS, kann aber mehr Daten verteilen und Widerruf verzögern. Opaque Tokens zentralisieren Wissen und machen den Live-Aufruf wichtiger. RFC 9767 lässt diese Modelle nebeneinander zu; die Architektur muss Frische und Offenlegung gemeinsam bilanzieren.

Asymmetrisches und symmetrisches Schlüsselmaterial unterscheiden sich ebenfalls. Ein öffentlicher Prüfschlüssel erlaubt keine neue private Signatur. Erhält der RS ein gemeinsames Geheimnis, kann er möglicherweise selbst eine Präsentation erzeugen. „Schlüsselgebunden“ allein beschreibt die Exfiltrationsgefahr nicht vollständig.

Eine Ressourcenreferenz soll ebenso undurchsichtig bleiben. Wer aus der Kennung interne Struktur herausliest, schafft Datenleck und Lock-in. Zufällige oder verschlüsselte Werte halten die Referenz austauschbar: Sie verweist auf einen beim AS gespeicherten Ressourcensatz, sie ist nicht aus eigener Kraft ein Recht.

Der nächste Hop beginnt neu

Muss RS1 einen RS2 aufrufen, sollte er das eingehende Token nicht einfach weiterreichen. RFC 9767 erlaubt einen abgeleiteten Token: RS1 sendet existing_access_token, tritt mit eigenem Schlüssel als Client auf und signiert eine neue Grant-Anfrage. Der AS prüft zunächst, ob das eingehende Token für RS1 geeignet war, und kann dann ein engeres Token für RS2 ausstellen.

Die Ableitung begrenzt Audience und Rechte und kann an den RS1-Schlüssel binden. Sie ähnelt dem OAuth Token Exchange darin, dass ein neues Artefakt neue Aussagen über Akteur, Subjekt und Ziel benötigt. Sie ist aber kein Ende-zu-Ende-Erfolgsnachweis.

Das neue Token beweist nicht, dass RS1 den Ursprungsauftrag korrekt verstand, RS2 die Aktion ausführte oder die Antwort den ersten Client erreichte. Jeder Hop braucht Eingang, Ableitungsanfrage, Ausgabe, Präsentation, örtliche Entscheidung und Wirkung als verbundene, aber getrennte Datensätze.

Vier Belege statt eines Flags

Die praktische Regel lautet: kein universelles Ereignis „authorized“. Beleg eins enthält die Introspektionsfrage und Antwort samt Zeit und Cache. Beleg zwei gehört zum Proof der aktuellen Nachricht. Beleg drei dokumentiert die RS-Richtlinie und Entscheidung. Beleg vier zeigt Commit, nachgelagerte Bestätigung oder Zustellung.

Negativtests müssen die Fugen treffen: richtige Signatur am falschen RS, zu hoher Zugriff, unbekannter Parameter, Proof-Replay, alter positiver Cache nach Widerruf, leere gefilterte Rechte, verlorene Antwort nach Commit und Weitergabe eines Bearer Tokens an RS2. Robustheit heißt, dass kein Teil ohne Evidenz den nächsten behauptet.

Quellen