1. Introduction (Einführung)

1. Introduction (Einführung)

Dieses Dokument definiert den Endpunkt für pushed authorization requests (PAR). Ein OAuth-[RFC6749]-Client kann damit die Nutzdaten einer Autorisierungsanfrage direkt an den Autorisierungsserver senden. Als Gegenleistung erhält er einen Request-URI, der bei einem späteren Aufruf des Autorisierungsendpunkts über den User-Agent auf diese Nutzdaten verweist.

In OAuth [RFC6749] werden Autorisierungsanfrageparameter üblicherweise als URI-Abfrageparameter per Umleitung im User-Agent übermittelt. Das ist einfach, birgt aber Herausforderungen:

• Es gibt keine kryptographische Integritäts- und Authentizitätsschutz. Ein Angreifer könnte z. B. den angeforderten Zugriffsbereich (scope) ändern oder den Kontext einer Zahlungstransaktion durch geänderte scope-Werte austauschen. Obwohl das Protokoll Mittel bietet, solche Änderungen zu erkennen, sind frühe Verhinderung von Manipulationen robuster.

• Es gibt keinen Mechanismus zur Vertraulichkeit der Anfrageparameter. Zwar ist HTTPS für den Autorisierungsendpunkt vorgeschrieben, die Daten laufen aber im Klartext durch den User-Agent; Abfragestrings können unbeabsichtigt in Webserver-Logs oder per Referer an andere Sites gelangen. Sind personenbezogene oder regulierte Daten in der Autorisierungsanfrage (z. B. in Identitäts- oder Open-Banking-Szenarien), kann die Auswirkung groß sein.

• Autorisierungs-URLs können sehr lang werden, insbesondere bei feingranularen Autorisierungsdaten, was zu Verarbeitungsfehlern führen kann.

JWT-Secured Authorization Request (JAR) [RFC9101] adressiert Sicherheitsaspekte, indem OAuth-Clients Autorisierungsanfrageparameter in einem Request Object kapseln, einem signierten und optional verschlüsselten JSON Web Token (JWT) [RFC7519]. Zur Größenbeschränkung führt JAR den Parameter request_uri ein, der eine Referenz auf das Request Object statt des Objekts selbst erlaubt.

Dieses Dokument ergänzt JAR um ein interoperables Vorgehen, die Nutzdaten direkt an den Autorisierungsserver zu senden und im Gegenzug einen request_uri-Wert zu erhalten, der bei einer späteren Autorisierungsanfrage am Server verwendet werden kann.

PAR stärkt die OAuth-Sicherheit, weil Clients auf einfache Weise eine vertrauliche und integritätsgeschützte Autorisierungsanfrage erhalten. Clients mit höheren Anforderungen, insbesondere kryptographisch belegbarer Nichtabstreitbarkeit, können JWT-basierte Request Objects gemäß [RFC9101] zusammen mit PAR nutzen.

PAR erlaubt dem Autorisierungsserver, den Client vor jeder Benutzerinteraktion zu authentisieren. Höheres Vertrauen in die Client-Identität ermöglicht früheres Ablehnen unzulässiger Anfragen und kann Client-Spoofing oder Manipulation/Missbrauch verhindern.

Hinweis: HTTP-POST-Anfragen an den Autorisierungsendpunkt über den User-Agent (Abschnitt 3.1 von [RFC6749], Abschnitt 3.1.2.1 von [OIDC]) könnten die oben genannten Größenlimits ebenfalls adressieren. Nach [RFC6749] sind sie jedoch optional; selbst wenn unterstützt, sind sie für klassische Webanwendungen praktikabel, für installierte mobile Apps aber kaum umsetzbar. Wie in [RFC8252] beschrieben, nutzen solche Apps plattformspezifische APIs, um die Autorisierungs-URI im Systembrowser zu öffnen; der erste Request ist dann auf GET beschränkt. POST würde erfordern, zuerst per GET eine vom App kontrollierte URI zu öffnen und die große Nutzlast zu übermitteln und die Antwort so zu gestalten, dass ein sitzübergreifendes Formular-POST zum Server erfolgt. PAR ist einfacher und bietet zusätzliche Sicherheitsvorteile.

Siehe 1.1. Introductory Example (Einführendes Beispiel) und 1.2. Conventions and Terminology (Konventionen und Terminologie).