Zusammenfassung

  • draft-ietf-oauth-deferred-token-response-00 stellt eine ausstehende Tokenanfrage durch einen sendergebundenen deferral_code dar; er ist kein Access Token und verleiht keinen Zugriff.
  • Der RFC-7009-Endpunkt liefert HTTP 200 nach wirksamer Stornierung ebenso wie ohne Zustandsänderung. Support-Metadaten und ein bestätigender Poll sind getrennte Belege.
  • Ein bereits übergebenes Access Token ist ein eigenständiges Credential. Der Widerruf des Deferral Codes widerruft es nicht und beweist kein Ende der Ressourcenoperation.

Mehrdeutigkeit als Schutz, nicht als Betriebsbeleg

OAuth-Widerruf soll einem Prüfer nicht verraten, ob ein eingesandter Wert gültig war. Diese Eigenschaft begrenzt Enumeration. Sie nimmt dem Statuscode zugleich die Fähigkeit, den internen Zustand zu bezeugen.

Die Revision 00 von Deferred Token Response behandelt Tokenentscheidungen, die nicht in einem Request abgeschlossen werden können. Menschliche Freigabe, Betrugsanalyse oder externe Prüfung laufen weiter. Wählt der Server nach Opt-in des Clients den Aufschub, antwortet der Token Endpoint mit HTTP 400, authorization_pending, einem opaken Code, Gültigkeit und Mindestabstand fürs Polling.

Der Code repräsentiert genau einen ausstehenden Antrag. Er ist weder Access noch Refresh Token und kein Authorization Code. Bei DPoP oder mTLS bleibt er an denselben Schlüssel beziehungsweise dasselbe Zertifikat gebunden.

Der Text ist ein aktiver OAuth-Working-Group-Entwurf, kein RFC und keine Aussage über reale Verbreitung. Seine Zustandsgrenzen sind dennoch ein brauchbarer Test für Betriebsbehauptungen.

Gleicher Feldname, andere Uhr

expires_in in der ersten Antwort beschreibt den Deferral Code. Nach Ablauf ergibt Polling expired_token. Die spätere erfolgreiche Tokenantwort kann ebenfalls expires_in enthalten; dann ist es die Lebensdauer des Access Tokens. Ein gemeinsamer Timer würde zwei Credentials verwechseln.

Auch interval muss erhalten bleiben. Der Wert steht nur in der ersten Antwort, nicht in jedem authorization_pending. Nach slow_down wächst er um mindestens fünf Sekunden. Ein System, das nur den letzten Response speichert, kann regelkonformes Polling nicht rekonstruieren.

Der Beleg muss deshalb Uhr, Objekt und Observer verbinden. Gültigkeit ist keine frei übertragbare Eigenschaft.

Der Callback ist nur ein Weckruf

Ein registrierter HTTPS-Endpunkt kann bei Erfolg, Fehler oder Stornierung benachrichtigt werden. Der Callback enthält den Deferral Code, aber weder Token noch Ergebnis. Er bedeutet nur, dass ein Poll jetzt die finale Antwort erhält.

Ein an den einzelnen Vorgang gebundenes Notification Token authentisiert die Nachricht. Fehlt es, braucht der Endpunkt andere Sicherung und sollte die Nachricht bis zum Poll nur als Hinweis behandeln. Selbst authentisiert beweist sie den Sender, nicht den Ausgang.

Revision 00 empfiehlt, im vereinbarten Rhythmus weiter zu pollen. Callback und Polling sind verschiedene Verfügbarkeitswege. Werden beide als Entscheidung interpretiert, entsteht keine Redundanz, sondern doppelte Scheinsicherheit.

Hinter 200 liegen gegensätzliche Zustände

Zur Stornierung sendet der Client den genauen Code an den Widerrufsendpunkt und sollte den Deferral-Code-Typ angeben. Erkennt der Server den Wert für diesen Client, wechselt er den Antrag atomar auf cancelled, unterdrückt noch nicht begonnene Callbacks und lässt spätere Polls access_denied liefern.

Unbekannte, fremde, bereits eingelöste, stornierte oder abgelaufene Werte erhalten ebenfalls HTTP 200, ohne Änderung. RFC 7009 verlangt diese nicht verratende Antwort.

Darum definiert DTR revocation_endpoint_token_type_values_supported. Ein Server mit Unterstützung listet den Deferral-Code-Typ. Ohne diese Ankündigung antwortet er trotzdem 200 auf den Widerruf. Der Entwurf warnt ausdrücklich vor still gescheiterter Stornierung.

Die Beweiskette lautet: Support-Metadaten im Zeitpunkt des Vorgangs, Widerrufsrequest samt Transportresultat, anschließend der Poll mit access_denied. 200 gehört hinein, aber nicht ans Ende.

Die Übergabegrenze teilt den Wettlauf

Hat der Server die positive Entscheidung bereits committed, aber das Token noch nicht ausgeliefert, führt die Stornierung zu „eingelöst und danach storniert“. Es wird kein Token ausgegeben; Polling endet mit access_denied.

Ist das Access Token schon beim Client, darf der Deferral-Code-Widerruf es nicht nebenbei entwerten. Beide Credentials haben unabhängige Lebensdauern. Zugriffsabbruch erfordert einen eigenen Tokenwiderruf und gegebenenfalls die Beobachtung am Resource Server.

Auch ein Callback kann bereits unterwegs sein. Unterdrückt werden muss nur eine noch nicht begonnene Zustellung. Eine späte Nachricht widerspricht der gültigen Stornierung nicht und darf keinen Workflow wieder öffnen.

„Storniert“ braucht daher eine Position: noch pending, resolved ohne Übergabe oder Token übergeben. Erst sie bestimmt die verbleibende Arbeit.

Während des Wartens kann die Zustimmung veralten

Deferral Codes können Stunden oder Tage leben. In dieser Zeit kann der Resource Owner seine Zustimmung entziehen, der Client deaktiviert oder die Sitzung beendet werden. Vor Ausgabe muss der Authorization Server die Voraussetzungen neu prüfen. Eine positive externe Freigabe ersetzt keine aktuelle Autorisierung.

Danach entscheidet der Resource Server über Scope und lokale Policy. Ein gültiges Token beweist keine zugelassene Einzeloperation; Zulassung beweist noch nicht deren Abschluss.

Ein kleiner Beleg, kein neues Zentralregister

Der lokale Datensatz sollte Issuer und Digest der Support-Metadaten, Client und Schlüsselreferenz, eine Einwegkorrelation statt des geheimen Codes, Ablauf und Pollintervall, Widerrufsversuche, Bestätigungspoll, Callbackstatus und Tokenübergabegrenze enthalten.

Der Entwurf verlangt, den Code wie ein Refresh-Token-Geheimnis zu behandeln und aus allgemeinen Logs zu entfernen. Nach Tokenübergabe kommt der getrennte Widerrufsbeleg hinzu; bei realem Operationsrisiko außerdem Ressourcenaufnahme und kontrolliertes Ergebnis.

Diese Form ist eine Minimum Initial Specification für Evidenz. Speicherung und Reaktion bleiben lokal. In Lu Hengs Reality Layers ist 200 eine symbolische Antwort, Stornierung eine Zustandsänderung, access_denied eine Protokollbeobachtung, Tokenwiderruf ein anderes Credential-Ereignis und die Ressourcenoperation das ausführbare Resultat. Mehr Kopien der ersten Nachricht ersetzen diesen Abstieg nicht.

Quellen

  1. Deferred Token Response rev00
  2. DTR-Versionsgeschichte
  3. DTR rev00 HTML
  4. DTR rev00 Text
  5. RFC 6749 — OAuth 2.0
  6. RFC 7009 — OAuth-Widerruf
  7. RFC 8628 — Device Authorization Grant
  8. RFC 8693 — Token Exchange
  9. RFC 8705 — OAuth mTLS
  10. RFC 9449 — OAuth DPoP
  11. RFC 9700 — OAuth Security BCP
  12. IANA OAuth Parameters
  13. Lu Heng — Minimum Initial Specification
  14. Lu Heng — On Reality Layers
  15. Lu Heng — Running Code Primary