Zum Hauptinhalt springen

1. Einleitung (Introduction)

"Das OAuth 2.0 Autorisierungs-Framework" [RFC6749] definiert den scope-Parameter, der es OAuth-Clients ermöglicht, den angeforderten Umfang, d.h. die eingeschränkte Fähigkeit eines Zugriffstokens, anzugeben. Dieser Mechanismus ist ausreichend, um statische Szenarien und grobkörnige Autorisierungsanfragen zu implementieren, wie z.B. "gib mir Lesezugriff auf das Profil des Ressourcenbesitzers". Er reicht jedoch nicht aus, um feinkörnige Autorisierungsanforderungen zu spezifizieren, wie z.B. "bitte lass mich einen Betrag von 45 Euro an Händler A überweisen" oder "bitte gib mir Lesezugriff auf Verzeichnis A und Schreibzugriff auf Datei X".

Diese Spezifikation führt einen neuen Parameter authorization_details ein, der es Clients ermöglicht, ihre feinkörnigen Autorisierungsanforderungen unter Verwendung der Ausdruckskraft von JSON [RFC8259] Datenstrukturen anzugeben.

Beispielsweise kann eine Autorisierungsanfrage für eine Kreditüberweisung (in mehreren Open-Banking-Initiativen als "Zahlungsinitiierung" bezeichnet) mithilfe eines JSON-Objekts wie diesem dargestellt werden:

{
  "type": "payment_initiation",
  "locations": [
    "https://example.com/payments"
  ],
  "instructedAmount": {
    "currency": "EUR",
    "amount": "123.50"
  },
  "creditorName": "Merchant A",
  "creditorAccount": {
    "bic": "ABCIDEFFXXX",
    "iban": "DE02100100109307118603"
  },
  "remittanceInformationUnstructured": "Ref Number Merchant"
}

Dieses Objekt enthält detaillierte Informationen über die beabsichtigte Zahlung, wie Betrag, Währung und Gläubiger, die erforderlich sind, um den Benutzer zu informieren und seine Zustimmung einzuholen. Der Autorisierungsserver (AS) und der jeweilige Ressourcenserver (RS) (der die Zahlungsinitiierungs-API bereitstellt) werden diese Zustimmung gemeinsam durchsetzen.

Für eine umfassende Diskussion der Herausforderungen, die sich aus neuen Anwendungsfällen im Bereich Open Banking und elektronischer Signatur ergeben, siehe [Transaction-Auth].

Zusätzlich zur Erleichterung benutzerdefinierter Autorisierungsanfragen führt diese Spezifikation auch eine Reihe gemeinsamer Datentypfelder zur Verwendung in verschiedenen APIs ein.

1.1. Konventionen und Terminologie (Conventions and Terminology)​

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind wie in BCP 14 [RFC2119] [RFC8174] beschrieben zu interpretieren, wenn und nur wenn sie in Großbuchstaben erscheinen, wie hier gezeigt.

Diese Spezifikation verwendet die Begriffe "Zugriffstoken", "Aktualisierungstoken", "Autorisierungsserver" (AS), "Ressourcenserver" (RS), "Autorisierungsendpunkt", "Autorisierungsanfrage", "Autorisierungsantwort", "Token-Endpunkt", "Grant-Typ", "Zugriffstoken-Anfrage", "Zugriffstoken-Antwort" und "Client", die durch "Das OAuth 2.0 Autorisierungs-Framework" [RFC6749] definiert sind.

Letztes Update am