Zusammenfassung

  • Der neue Individual Draft verlangt für jede Txn-AT-Anfrage eine Policy-Auswertung und begrenzt das JWT auf einen Resource Server und ungefähr fünf Minuten.
  • Dadurch wird der Authorization Server zum kritischen Entscheidungs- und Beobachtungspunkt; kurze Tokens beweisen weder konsistente Policy noch Single Use, Ausführung oder Ergebnis.

draft-tulshi-oauth-transactional-access-tokens-00 erschien am 29. September 2026. Es ist ein Individual Internet-Draft mit Standards-Track-Absicht, kein OAuth-WG-Dokument, kein IETF-Konsens und kein RFC. Belege für Implementierung, Interoperabilität oder Betrieb fehlen. Die Aussage betrifft eine Architektur in Arbeit.

Ein Txn-AT folgt RFC 9068, trägt aber typ: txnat+jwt. Ein unbekannter Empfänger soll es ablehnen, statt es als gewöhnliches Access Token zu behandeln. aud nennt genau einen Resource Server. txn kennzeichnet die Transaktion für diese Audience; tctx und rctx enthalten vom Authorization Server bewerteten Kontext.

Die Anfrage stützt sich weiterhin auf Token Exchange, Refresh Token oder Client Credentials. Der Server muss jedes Mal Policy ausführen und darf trotz gültiger Grundlage ablehnen. Für eine neue Transaktion erzeugt er außerdem einen opaken Handle, gebunden an Client, Subject und gegebenenfalls denselben Sender-Key.

Der Handle kann weitere audience-spezifische Tokens anfordern. Daraus entsteht eine Beweiskette: dauerhaftes Credential, aktueller Policy-Entscheid, Handle, einzelnes Txn-AT, internes Transaction Token und spätere Ausführung. Wer alles als „autorisierte Transaktion“ zusammenfasst, verliert die Fehlergrenze.

Der Draft lässt Consent und Client Authority ausdrücklich dauerhaft. Ein einmaliger Authorization-Code-Flow kann ein Refresh Token erzeugen; spätere Transaktionen brauchen keine erneute Nutzerinteraktion. Ein Dieb der Wurzel muss Policy passieren, besitzt aber weiterhin das Recht, neue Entscheidungen anzufordern.

Die Qualität hängt daher an der aktuellen Auswertung. Client-Werte dürfen nicht ungeprüft in tctx oder rctx landen. Subject, Authentisierung, Attestation, Resource, Authorization Details und Umgebung müssen frisch sein. Eine gültige Signatur schützt eine Serveraussage, nicht deren Richtigkeit oder Gleichheit über Regionen.

Audience-spezifische txn-Werte verhindern einen einfachen Vergleich zwischen Resource Servern. Andere Join Keys bleiben: client_id, Timing, Subject und charakteristischer Kontext. Der Authorization Server kennt die interne Transaktion und beobachtet alle Anforderungen. Seitliche Korrelation sinkt, zentrale Sicht wächst.

Eine HMAC-Ableitung aus interner ID und Audience spart Mapping-Zustand. Dafür werden K_txn, Rotation und retired keys Teil der Audit-Infrastruktur. Ein gemeinsamer Verlust von Key und internem Zustand rekonstruiert die Cross-Resource-Verknüpfung.

Replay wird nicht beseitigt. Ein Bearer Txn-AT kann während seiner Laufzeit erneut verwendet werden. DPoP oder Mutual TLS sind empfohlen; jti-Tracking ist optional. Fünf Minuten können für wiederholte Zahlungen, Löschungen oder Konfigurationswechsel lang sein.

Auch txn ist kein Business-Idempotency-Key. Es erklärt den Autorisierungskontext, nicht ob zwei Requests einen Effekt bilden. Bei Erfolg von RS1 und Fehler von RS2 liefert das Token keine Atomicity. Anwendungsspezifische Request-ID, Commit-Beleg und Compensation bleiben nötig.

Der Authorization Server liegt nun im kritischen Pfad jeder Transaktion. Issuance-Latenz verlängert den Auftrag, Ausfall blockiert geschützte Ressourcen, Volumen skaliert mit Transaktionen. Regionale Verteilung verbessert Nähe, erzeugt aber Konsistenzfragen für Policy, Handles, Keys und Replay-Signale.

Negative Tests müssen wrong typ, mehrere Audiences, abgelaufene Handles, anderen Client oder Subject, stale context und Ordinary-Token-Downgrade abdecken. Ein Metadata-Flag beweist nicht, dass alle produktiven Routen fail closed sind.

Die dünne gemeinsame Schicht darf Typ, Audience, Provenance und bewerteten Kontext transportieren. Sie darf den Policy Engine nicht zum universellen Wahrheitsgeber machen und Token Acceptance nicht als Outcome ausgeben. Erst getrennte Receipts zeigen, ob die Begrenzung im Betrieb hielt.

Quellen