Zusammenfassung

  • draft-ietf-oauth-rar-metadata-remediation-00 erlaubt einem Ressourcenserver, auf einen gültigen, aber unzureichend autorisierten OAuth-Aufruf mit handlungsfähigen Rich-Authorization-Request-Objekten zu antworten, die der Client in einen neuen Autorisierungsvorgang übernehmen kann.
  • Der Ressourcenserver erteilt keine Berechtigung. Er beschreibt, was ihm genügen würde; Autorisierungsserver und Ressourceneigentümer prüfen, wenden Richtlinien an, stimmen zu, schränken ein oder lehnen ab. Danach entscheidet der Ressourcenserver erneut über den Zugriff.
  • Daniel Kade schlägt einen Nachweis der Berechtigungsdifferenz vor: Er verbindet fehlgeschlagene Operation, vorhandene Autorität, vorgeschlagene Details, Schemaherkunft, Einwilligung, tatsächlich erteilte Details und das Ergebnis am geschützten System. Dieser Nachweis ist Governance-Praxis, keine Vorgabe des Entwurfs.

Eine Ablehnung, die den nächsten Antrag mitliefert

Eine Treasury-Anwendung möchte ein Lastschriftmandat anlegen. Das Zugriffstoken ist gültig, enthält aber keine Autorisierungsdetails für diesen Vorgang. Herkömmliche Fehlerbehandlung würde vielleicht eine allgemeine Ablehnung anzeigen und die Nutzerin an eine andere Stelle schicken, um „mehr Zugriff“ zu erhalten. Was mehr bedeutet, ergibt sich dann aus Produktdokumentation, Konventionen oder einer privaten Integrationsvereinbarung.

Der erste Arbeitsgruppenentwurf zu RAR-Metadaten und Fehlerbehebung zeichnet einen interoperableren Weg. Ein Ressourcenserver kann HTTP 401 mit dem neuen Fehler insufficient_authorization zurückgeben. Der Parameter authorization_remediation kann aus dem gescheiterten Aufruf abgeleitete authorization_details und optional eine authorization_reference enthalten. Der Client darf nach einem passenden vorhandenen Token suchen oder die gelieferten Details unmittelbar in eine neue OAuth-Autorisierungsanfrage einsetzen.

Damit schließt der Entwurf eine echte Lücke. RFC 9396 gab OAuth eine strukturierte Sprache für fein zugeschnittene Berechtigungen. Er erklärte jedoch weder die allgemeine Entdeckung aller Detailtypen noch die Erholung von einem geschützten Aufruf, dessen Token nicht genügt. Revision 00 ergänzt einen Metadaten-Endpunkt für Schemata und Beispiele, ein Fehlersignal und Regeln für die Remediation.

Das Dokument ist ein aktiver Arbeitsgruppenentwurf vom 23. August 2026. Es löste einen individuellen Entwurf ab, nachdem das Protokoll der OAuth-Sitzung auf der IETF 126 Unterstützung für das Problem, Diskussion über die Lösung und einen Aufruf zur Adoption festhielt. Es ist kein RFC, hat keinen IESG-Telechat-Termin und enthält keine belastbaren Einführungsergebnisse. Vorgeschlagene Registrierungen sind noch keine vollzogenen IANA-Zuweisungen.

Diese Einordnung schmälert den Nutzen nicht. Ein Ressourcenserver, der die fehlende Berechtigung präzise ausdrücken kann, hilft mehr als einer, der nur „verboten“ sagt. Die hilfreiche Antwort ist jedoch nicht neutral: Sie trägt einen Vorschlag für neue Autorität in den Client.

Der Ressourcenserver formuliert Suffizienz, nicht die Gewährung

Die handlungsfähigen Details werden laut Entwurf aus dem fehlgeschlagenen Ressourcenaufruf gebildet. Wenn sie in einer erfolgreichen neuen Gewährung enthalten sind, sollen sie die Anforderungen der Ressource erfüllen. Der Ressourcenserver wird somit zum Urheber eines folgenreichen Vorschlags: Er benennt die strukturierte Autorität, die er vor Ausführung der Operation sehen möchte.

Zur nutzbaren Berechtigung wird dieser Vorschlag erst nach mehreren Kontrollgrenzen. Der Client entscheidet, ob er die Challenge verarbeitet. Der Autorisierungsserver validiert den Detailtyp, wendet seine Richtlinien an und führt den passenden Grant aus. RFC 9396 verlangt die Darstellung der angeforderten Rechte zur Einwilligung; der Ressourceneigentümer kann nur einen Teil gewähren oder ganz ablehnen. Die Tokenantwort nennt die tatsächlich erteilten Details. Schließlich prüft der Ressourcenserver Token und Operation erneut.

Darum wäre die Aussage falsch, der Ressourcenserver verschaffe sich selbst eine Erlaubnis. Ebenso falsch wäre die Beschwichtigung, wegen der verbleibenden Einwilligung habe sich nichts geändert. Es ist ein neuer Antrag auf Autorität entstanden. Automatisierung kann ihn so reibungslos durch die Entscheidungskette tragen, dass sein materieller Unterschied kaum sichtbar bleibt.

Ein Client könnte das Lesen eines Kontos versucht haben, während das Remediation-Objekt ein wiederkehrendes Mandat beschreibt. Ein Gerät könnte eine einzelne Aktion anstoßen, während die Risikolage den Server eine stärkere Zeremonie oder einen genaueren Datensatz fordern lässt. Aus Sicht der lokalen Richtlinie kann der Vorschlag enger, weiter, gleichwertig, unvergleichbar oder unbekannt sein.

Die Zahl der JSON-Felder beantwortet diese Frage nicht. RFC 9396 erklärt ausdrücklich, dass beliebige Autorisierungsdetails nicht generisch verglichen werden können, weil die jeweilige API ihre Semantik bestimmt. Weniger Eigenschaften bedeuten nicht automatisch weniger Macht. Ein ausgelassenes Limit kann einen Standardwert aktivieren, eine Liste kann eine Vereinigung ausdrücken, und eine Ressourcenkennung kann das Schutzobjekt vollständig wechseln.

Die opake Referenz ist ein Suchschlüssel, kein Urteil

Die optionale authorization_reference soll Clients bei der Tokenauswahl von der Interpretation komplexer Objekte entlasten. Für gleiche oder semantisch gleichwertige Details sollte der Ressourcenserver einen stabilen opaken Wert ableiten. Der Client kann ihn mit Referenzen vergleichen, die für dieselbe Endnutzer-Sitzung und denselben Ursprung des Ressourcenservers neben Tokens liegen.

Der Zweck bleibt bewusst begrenzt. Der Client darf den Wert nicht deuten oder serverübergreifend verwenden. Für einmalig nutzbare Tokens soll der Server ihn nicht liefern. Auch ein Treffer garantiert keinen Erfolg: Eine Einwilligung kann widerrufen, die Risikolage verändert oder nur ein Teil der ursprünglichen Anfrage erteilt worden sein.

Umgekehrt beweist eine andere Referenz keine größere Berechtigung. Der Entwurf nennt ein Token für wiederkehrende Belastungen bis 100, das eine Anfrage über 80 abdecken kann, obwohl die Referenzen verschieden sind. Enthaltensein ist eine semantische Beziehung und keine Gleichheit opaker Zeichenfolgen. Die Referenz beschleunigt die Suche in einer Token-Sammlung; über die Zulässigkeit des Aufrufs entscheidet weiterhin die Ressource.

Diese Trennung geht in Telemetrie leicht verloren. Eine Meldung wie „Referenz stimmt überein“ kann in einem Dashboard als „Autorisierung erfüllt“ erscheinen, obwohl sie nur die Auswahl eines Kandidaten belegt. Eine „geänderte Referenz“ kann umgekehrt automatisch einen neuen Flow auslösen, ohne zu zeigen, ob sich die verlangte Autorität überhaupt wesentlich verändert hat.

Ein Schema prüft Gestalt, nicht Zweck

Revision 00 schlägt außerdem einen Metadaten-Endpunkt für Typen von Autorisierungsdetails vor. Ein Typ kann eine informative Versionsangabe, Beschreibung, Dokumentationsadresse, Beispiele und entweder ein eingebettetes JSON Schema oder einen schema_uri veröffentlichen. Das Schema muss genau ein Objekt beschreiben und dessen type-Feld auf die betreffende Kennung einschränken.

Das hilft beim Erzeugen und Validieren. Zum politischen Orakel werden Metadaten dadurch nicht. Die Beschreibung ist kein Eingang für Autorisierungs- oder Validierungsentscheidungen, Beispiele sind nicht normativ und die Versionsangabe begründet keine semantische Aushandlung. Ein Schema kann bestätigen, dass ein Betrag als Zeichenfolge in einem Pflichtfeld steht. Es kann nicht feststellen, ob der Betrag für diese Person angemessen ist, ein Dauermandat dem ursprünglichen Zweck entspricht oder die Einwilligungsoberfläche die Konsequenz verständlich gemacht hat.

Die Herkunft des Schemas muss dennoch nachvollziehbar bleiben. Zwischen Challenge und neuem Antrag kann sich eine Typdefinition ändern, sodass ähnlich aussehende Felder nicht mehr dasselbe bedeuten. Ein Betreiber braucht den verwendeten Dokumentstand oder Schema-Digest und die Version der Richtlinienimplementierung. Nur den Typnamen zu speichern, entfernt die relevante Entscheidungsfläche.

Metadaten können auch die Vertrauensroute verändern. Unterstützt der bisherige Autorisierungsserver einen benötigten Typ nicht, gestattet der Entwurf die Entdeckung alternativer Server über Protected Resource Metadata. Das dient der Interoperabilität, doch ein neuer Aussteller ist kein transparenter Wiederholungsendpunkt. Registrierung, Authentifizierung, Einwilligung, Aufbewahrung und Richtlinien können anders sein.

Ein Nachweis der Berechtigungsdifferenz

Ich schlage einen Nachweis der Berechtigungsdifferenz vor. Er ist weder neuer OAuth-Claim noch Header, Registry oder Protokollforderung. Es handelt sich um eine betriebliche Aufzeichnung um den Remediation-Vorgang, damit erfolgreiche Erholung nicht ausblendet, dass ein neuer Autoritätsvorschlag ins System gelangte.

Der Nachweis beginnt bei der Ablehnung. Er identifiziert Endnutzer-Sitzung und Ressourcenserver-Ursprung, verpflichtet sich kryptografisch auf den gescheiterten Aufruf und seine Operationsklasse und hält effektive Scopes oder Autorisierungsdetails des vorgelegten Tokens fest. Kontonummern, Patientendaten oder vertrauliche Transaktionswerte gehören nicht in allgemeine Logs; enge opake Verweise oder kurzlebige gesalzene Commitments genügen.

Dann folgt der Vorschlag: ein Digest der decodierten authorization_remediation, eine sichere verständliche Darstellung des gewünschten Effekts, die Referenz, der Detailtyp, Schemaadresse oder -digest, Informationsversion und Abrufzeit der Metadaten. Der Client hält fest, ob er den Vorschlag als unverändert, enger, weiter, unvergleichbar oder unbekannt einstufte, einschließlich des typspezifischen Vergleichers und seiner Richtlinienversion.

Danach kommt die Disposition. Hat der Client abgelehnt, ein bestehendes Token gefunden, einen neuen Flow begonnen, eine Bestätigung verlangt oder an einen Menschen eskaliert? Welcher Autorisierungsserver wurde gewählt, und wechselte der Aussteller? Welche Fassung der Einwilligungsansicht erschien? Was hat der Ressourceneigentümer akzeptiert, eingeschränkt oder verweigert? Welche Details weist die Tokenantwort tatsächlich als erteilt aus?

Zum Schluss verfolgt der Nachweis die Wiederholung. Eine Referenzverknüpfung bleibt auf Sitzung und Ursprung beschränkt. Gezählt werden der Versuch mit einem vorhandenen Token und der frische Autorisierungslauf. Hinzu kommen die endgültige Ressourcenentscheidung und der Effekt der Operation oder ein Rollback-Verweis. Token, Secrets oder vollständige sensible RAR-Objekte werden nicht aus Bequemlichkeit dupliziert.

So kann jeder Akteur eine begrenzte Aussage belegen. Der Ressourcenserver weist seinen Vorschlag nach, der Client dessen Behandlung, der Autorisierungsserver Darstellung und Ausgabe. Die Entscheidung des Eigentümers wird mit dem tatsächlich Gewährten verbunden. Ein erfolgreicher OAuth-Austausch wird trotzdem nicht zum Beweis dafür, dass die geschäftliche Operation korrekt abgeschlossen wurde.

Datenschutz ist Teil der Kontrolle

RAR-Objekte können Konten, Gesundheitsakten, Standorte oder Transaktionsbedingungen beschreiben. Der Remediation-Entwurf rät Ressourcenservern, sensible Daten aus handlungsfähigen Details herauszuhalten, und erlaubt opake Handles. Autorisierungsserver sollen Privatsphäre und Tokengröße berücksichtigen, bevor sie genehmigte Details in JWT-Zugriffstokens einbetten; wo passend, steht authentisierte Introspection zur Verfügung.

Der Differenznachweis braucht dieselbe Zurückhaltung. Sein Zweck ist die Beziehung zwischen Entscheidungen, nicht eine zweite Datenbank geschützter Inhalte. Hashing allein anonymisiert schwache Werte nicht, weil vorhersehbare Kontobezeichnungen oder Beträge erraten werden können. Commitments brauchen Salt, kurze Aufbewahrung und Zugriffsschutz. Eine verständliche Darstellung sollte nur den nötigen Effekt nennen, etwa „wiederkehrende Belastung bis zur Richtliniengrenze“, aber keine Kontonummer kopieren.

Auch die Quellen dürfen nicht verschmelzen. Ein vom Ressourcenserver gelieferter Handle ist keine Aussage des Nutzers. Eine Schemabeschreibung ist kein Einwilligungstext. Erteilte Tokendetails beweisen nicht, dass die Oberfläche gelesen wurde. Klare Provenienz macht den Nachweis sperriger und zugleich ehrlicher.

Fehlerbehebung kann zur Richtlinienautomation werden

Der Entwurf enthält wichtige Schleifenbremsen. Bei derselben Referenz sollte der Client höchstens ein passendes gespeichertes Token und danach genau einen neuen Autorisierungsvorgang versuchen. Eine andere Referenz darf einen weiteren Lauf ermöglichen, begrenzt durch ein implementierungsspezifisches Maximum. Tokens bleiben nach Endnutzer-Sitzung getrennt.

Das beschränkt mechanische Wiederholung, entscheidet aber nicht über die inhaltliche Angemessenheit. Eine Folge verschiedener Referenzen kann legitimen Kontextwechsel, schwankende Richtlinien oder eine Treppe wachsender Autoritätsvorschläge anzeigen. Wer nur gleiche Referenzen zählt, kann formal regelkonform immer wieder angrenzende oder weitergehende Grants erfragen.

Eine brauchbare Betriebsgrenze hat deshalb zwei Dimensionen: die Anzahl der Protokollversuche und ein Budget für Autoritätsänderung. Unerwarteter Aussteller, folgenreiche Aktion, neue Ressourcenklasse, längere Dauer, geändertes Schema oder unvergleichbares Objekt müssen die stille Erholung beenden und eine neue Erklärung oder verantwortliche Prüfung auslösen.

Die bleibende Lehre lautet: Eine handlungsfähige Ablehnung ist wertvoll, weil sie eine Interoperabilitätslücke in eine strukturierte Entscheidung verwandelt. Gefährlich wird sie, wenn jedes strukturierte Ereignis als bloße Technik gilt. Ein Retry wiederholt eine Operation unter vorhandener Autorität; RAR-Remediation kann andere Autorität anfordern. Der Nachweis muss diese Differenz sichern, bevor der endgültige Effekt ihre Rekonstruktion unmöglich macht.

Quellen

  1. Entwurf zu OAuth-RAR-Metadaten und Remediation
  2. Versionsgeschichte des Entwurfs
  3. Datatracker-API-Eintrag
  4. Arbeitsgruppenrevision 00
  5. Textfassung der Revision 00
  6. Früheres Quellrepository
  7. Protokoll der OAuth-Sitzung auf IETF 126
  8. Charta der OAuth-Arbeitsgruppe
  9. RFC 9396: Rich Authorization Requests
  10. RFC 6750: Bearer Token Usage
  11. RFC 8414: Authorization Server Metadata
  12. RFC 9728: Protected Resource Metadata
  13. RFC 9470: Step Up Authentication Challenge
  14. RFC 7662: Token Introspection
  15. RFC 9068: JWT Access Token Profile
  16. RFC 9126: Pushed Authorization Requests
  17. RFC 9101: JWT-Secured Authorization Request
  18. IANA-OAuth-Parameter
  19. XML-Quelle der Revision 00
  20. Issues des früheren Repositories