Vereinfachter Zusammenhang

Prinzipiell wollen wir mit unserem Kanal (Client) Daten (Resources) von einem HTTP(S)-Server (Resource Server) erhalten.

Dazu benötigen wir einen Access Token, den wir davor von einem Authorization Server erhalten. Der Access Token wird intern im HTTP(S)-Kanal hinterlegt.

In der folgenden Maske geht es lediglich darum, wie wir diesen Access Token bekommen. Dazu benötigen Sie zuerst einen Authorization Grant.

Hinweis: Siehe auch https://tools.ietf.org/html/rfc6749#section-1.1.

Einstellungen

(1) Application ID: Wird automatisch eingetragen. Beispiel: "_data1606366806421015".

(2) Scope: OAuth-2.0-Scopes bieten eine Möglichkeit, den Umfang des Zugriffs eines Access Tokens zu begrenzen. Beispielsweise kann einem Access Token, der für eine Client-Anwendung ausgegeben wurde, Lese- und Schreib-Zugriff auf geschützte Ressourcen oder nur Lese-Zugriff gewährt werden. Hinweis: Die Eingabe einzelner Werte können mit der Eingabe-Taste abgeschlossen werden. Sie können aber auch mehrere Werte, jeweils durch ein Leerzeichen getrennt, auf einmal eingeben.

(3) Optional settings: Hier können zusätzliche Parameter (Query oder Body) und Header angegeben werden.

(4) Grant type: Es gibt verschiedene Methoden (Authorization Code, Client Credentials, Password Credentials), mit denen Sie einen Authorization Grant bekommen können. Siehe die entsprechenden Unterabschnitte. Hinweis: Siehe auch https://tools.ietf.org/html/rfc6749#section-1.2.

(5) Endpoint URL: Die Token-Endpoint-URL. Von dieser URL des Authorization Servers erhält der Kanal den Access Token nach erfolgreichem Authorization Grant (4). Beispiel: "https://some-server/oauth/token".

(6) JSON Request: Falls die Checkbox gesetzt ist, dann wird der Body aller Requests im JSON-Format gesendet mit Content-Type application/json, ansonsten mit Content-Type application/x-www-form-urlencoded.

(7) Redirect URL: Wird automatisch eingetragen und ist nur aktiv für den Wert Authorization Code in (4), siehe entsprechenden Abschnitt unten. Hinweis: Die IP muss g egebenenfalls angepasst werden, wenn Ihr Authorization Server nicht in Ihrem internen Netz ist. D. h. Sie müssen dann die IP eintragen, mit der Ihr Lobster Integration (Integration Server) von außerhalb des internen Netztes erreichbar ist. Ihr Netzwerk-Administrator wird Ihnen dabei weiterhelfen können. Beispiel: "https://192.168.132.193/dw/oauth2/_data1606366806421015". Beispiel für "OAuth URL": "https://some-server/oauth/authorize".

(8) Trace/Debug: Ist diese Checkbox gesetzt, dann finden Sie in (10) zusätzliche Trace-Meldungen.

(9) Access Token holen: Drücken Sie hier, um den Access Token über die Token Endpoint URL (5) des Authorization Servers. Hinweis: In den Zusatzkennungen sieht man den Access Token in einem Eintrag mit dem Namen SYS_HTTP_OAUTH2 und einen Refresh Token in einem Eintrag mit dem Namen SYS_HTTP_OAUTH2_REFRESH.

(10) Logs Allg. Meldungen: Springt zum Bereich Allgemeine Meldungen des Control Centers.

Authorization Grants

Grant Type "Authorization Code"

(11) Client ID, Client Secret: Die Client ID ist eine öffentliche Kennung für Applikationen (hier unser Kanal). Das Client Secret ist nur dem Client und dem Authorization Server bekannt. Hinweis: Beide werden vom Authorization Server im Vorfeld generiert und bereitgestellt.

(12) Sende client credentials im Header: Wenn diese Checkbox gesetzt ist, dann werden die Credentials (Client ID, Client Secret) im Header statt im Body des Requests an den Authorization Server angegeben.

(13) OAuth URL: Die Authorization Endpoint URL. Über diese URL des Authorization Servers erreichen Sie eine Seite, auf der Sie manuell Zugangsdaten (für den Resource Server) eingeben können (letztlich validiert vom Authorization Server). Über (7) gelangen Sie zurück zu Lobster Integration. Dadurch erhalten Sie (vereinfacht beschrieben) den Authorization Grant vom Authorization Server und dann den Access Token (und evtl. ein Refresh Token). Hinweis: Siehe auch https://tools.ietf.org/html/rfc6749#section-4.1.

Grant Type "Client Credentials"

(14) Client ID, Client Secret: Die Client ID ist eine öffentliche Kennung für Applikationen (hier unser Kanal). Das Client Secret ist nur dem Client und dem Authorization Server bekannt. Hinweis: Beide werden vom Authorization Server im Vorfeld generiert und bereitgestellt.

Beide werden an den Authorization Server gesendet. Dadurch erhalten Sie den Authorization Grant und dann den Access Token. Hinweis: Siehe auch https://tools.ietf.org/html/rfc6749#section-4.4.

(15) Sende client credentials im Header: Wenn diese Checkbox gesetzt ist, dann werden die Credentials (Client ID, Client Secret) im Header statt im Body des Requests an den Authorization Server angegeben.

Grant Type "Password Credentials"

(16) Client ID, Client Secret: Die Client ID ist eine öffentliche Kennung für Applikationen (hier unser Kanal). Das Client Secret ist nur dem Client und dem Authorization Server bekannt. Hinweis: Beide werden vom Authorization Server im Vorfeld generiert und bereitgestellt. Wichtiger Hinweis: Beide Felder sind in diesem Fall an sich keine Pflicht, manche Authorization Server verlangen sie aber!

(17) Sende client credentials im Header: Wenn diese Checkbox gesetzt ist, dann werden die Credentials (Client ID, Client Secret) im Header statt im Body des Requests an den Authorization Server angegeben.

(18) Eigene Kennung, Eigenes Kennwort: Wenn Sie Zugangsdaten zuvor vom Resource Server erhalten haben, können Sie diese verwenden, um vom Authorization Server den Authorization Grant zu erhalten (dieser prüft die Zugangsdaten für den Resource Server) und dann den Access Token (und evtl. ein Refresh Token). Siehe auch (16). Hinweis: Siehe auch https://tools.ietf.org/html/rfc6749#section-4.3.

DATEV OAuth2 Hybrid Flow

Siehe Abschnitt DATEV OAuth2 Hybrid Flow für eine spezielle OAuth2-Variante von DATEV.