Zum Hauptinhalt springen
Version: 1.1.0

Häufig gestellte Fragen (FAQ)

Hier finden Sie Antworten auf häufig gestellte Fragen zur Umsetzung des OAuth PoCs für XBezahldienste.

Wie genau ist der OAuth2 Server strukturiert?​

Für den PoC wird ein OAuth-Server auf Basis von Connect2id (öffnet in neuem Tab) eingesetzt. Der Server wird vom Produkt-Team FIT-Connect betrieben und bereitgestellt. Das Setup ist speziell für Testzwecke konfiguriert und bietet die notwendige Funktionalität für den PoC.

warnung

Der Server ist ausschließlich für Testzwecke und die Implementierung im Rahmen des PoCs vorgesehen. Ein Einsatz im Produktivbetrieb ist nicht zulässig.

Der PoC OAuth-Server implementiert ein vereinfachtes Modell ohne Trennung von Tenants (Single-Tenancy). Alle PoC-Teilnehmer operieren daher innerhalb desselben technischen Kontexts.

Die Konfiguration verwendet eine Wildcard-Audience (*), wodurch die APIs der Bezahldienstleister (Resource Server) nicht explizit registriert werden müssen. Lediglich die Clients (Resource Owner) müssen angelegt werden.

info

Diese Konfiguration ohne Tenants und ohne dedizierte Resource-Server entspricht nicht den Best Practices für Produktivsysteme. Für den PoC wurde dieses Setup gewählt, um den technischen und organisatorischen Aufwand zu minimieren.

Ist der Bezahldienstleister der Resource Owner?​

In unserem Machine-to-Machine (M2M) Szenario ist der Online-Dienst "Client" und "Resource Owner", und der Bezahldienst der "Resource Server".

Im OAuth-Kernkonzept sind vier Hauptakteure beteiligt:

  • Resource Owner: Die Entität, die den Zugriff auf Ressourcen gewährt, was häufig (aber nicht immer, z.B. bei M2M) ein Endnutzer ist.
  • Resource Server: Die Entität, die die geschützten Ressourcen hostet, typischerweise eine Backend-API. Der Resource Server empfängt und validiert ein Access Token bei der Verarbeitung von Anfragen für Ressourcen.
  • Client: Die Anwendung, die im Namen des Resource Owners auf Ressourcen zugreifen muss. Dies geschieht durch das Senden eines Access Tokens an den Resource Server.
  • Authorization Server: Die Entität, die den Resource Owner authentifiziert und dann Access Tokens an den Client ausgibt.

Die OAuth 2.0 Terminologie kann sich leicht von den alltäglichen Begriffen für diese Komponenten unterscheiden. In vielen Szenarien kann man "Resource Owner" durch "Benutzer", "Client" durch "Anwendung" und "Resource Server" durch "API" ersetzen.

Kann der Bezahldienstleister die Mandanten, mit denen er arbeitet, als Client anlegen oder anlegen lassen?​

info

Der Begriff "Mandant" ist ein fachliches Konzept (der Bezahldienstleister) und daher nicht Teil des OAuth2-Frameworks. OAuth2 operiert ausschließlich mit technischen Clients. Ein einzelner OAuth2-Client kann dabei durchaus Anfragen für mehrere fachliche Mandanten stellen. Diese Unterscheidung zwischen technischer und fachlicher Ebene ist für das Verständnis essentiell.

Im Rahmen des PoC werden die notwendigen Clients im OAuth-Server durch das FIT-Connect-Team für Sie angelegt. Nutzen Sie dafür bitte folgendes Formular: https://fit-connect-support.fjd.de/ (öffnet in neuem Tab)

Gibt es die Möglichkeit, je Mandant eines Bezahldienstleisters eine oder mehrere Informationen über die Access-Token-Payload mitzuschicken (z.B. ID des Mandanten)?​

Auch hier ist die Unterscheidung zwischen fachlicher und technischer Ebene essenziell.
Die Payload des Access-Tokens kann ausschließlich Informationen enthalten, die zum Zeitpunkt der Client-Registrierung bekannt sind. Wenn ein Client mehrere Mandanten eines Bezahldienstleisters bedient und diese erst zur Laufzeit ermittelt werden, kann diese Information prinzipbedingt nicht Teil des Access-Tokens sein.

In der Payload des Access-Tokens können claims verwendet werden, um den Client eindeutig zu identifizieren.

Standardmäßig wird hierfür das Subject-Claim (sub) verwendet. Eine fundierte Einführung zu diesem Thema finden Sie hier: https://www.cerberauth.com/blog/oauth2-access-token-claims/ (öffnet in neuem Tab)

Mit dem Subject können Sie den Client, der auf Ihre API zugreift, eindeutig identifizieren. Dies stellt jedoch in der Regel nur die technische Identifikation dar. Für die fachliche Zuordnung eines Requests empfiehlt sich die Verwendung der dafür konzipierten EfA-Parameter OriginatorId und EndpointId, die als Teil der API-Anfrage übermittelt werden.

tipp

Beachten Sie hierbei auch die Dokumentation zur API-Parametrisierung im XBezahldienste-Standard: https://docs.fitko.de/xbezahldienste/APIDoku/API-Parametrisierung/

Ist die gemeinsame Entwicklung eines Zielbilds für die künftige Registrierung als Client mit im Scope des PoC?​

Nein, die Entwicklung eines Zielbilds für die künftige Client-Registrierung ist nicht direkter Bestandteil des PoC. Die während des PoC gesammelten Erkenntnisse werden jedoch in die nachfolgende Konzeption des Zielbilds einfließen. Die Nortal AG wird nach Abschluss des PoC einen umfassenden Bericht erstellen, der diese Erkenntnisse dokumentiert und daraus resultierende technische und organisatorische Anforderungen ableitet.

Wie erfolgt die Zuordnung zu einem Benutzer bzw. Mandanten? Um bspw. die Berechtigungen zu laden?​

Die Zuordnung zu einem Benutzer bzw. Mandanten erfolgt über zwei Ebenen:

  1. Technische Identifikation: Über das Subject-Claim (sub) im Access-Token wird der technische Client eindeutig identifiziert. Dies ermöglicht die grundlegende Authentifizierung und Autorisierung auf API-Ebene.

  2. Fachliche Zuordnung: Für die fachliche Zuordnung eines Requests zu einem spezifischen Mandanten empfiehlt sich die Verwendung der EfA-Parameter:

Diese Parameter werden als Teil der API-Anfrage übermittelt und ermöglichen die eindeutige Zuordnung zu einem fachlichen Mandanten, unabhängig vom technischen OAuth2-Client.

info

Wie bereits erläutert, ist der Begriff "Mandant" ein fachliches Konzept und nicht Teil des OAuth2-Frameworks. Die Berechtigungen werden auf Basis des technischen Clients geladen, während die fachliche Zuordnung über die API-Parameter erfolgt.