OAuth 2.0 (Client)
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 und Abschnitt OAuth2 (Client) - Tutorial.
Allgemeine Einstellungen
(1) Wird automatisch eingetragen.
(2) 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.
(3) Hier können zusätzliche Parameter (Query oder Body) und Header angegeben werden.
(4) 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) Die Token-Endpoint-URL. Von dieser URL des Authorization Servers erhält der Kanal den Access Token nach erfolgreichem Authorization Grant (4).
(6) 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) 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 _data (Integration Server) von außerhalb des internen Netztes erreichbar ist. Ihr Netzwerk-Administrator wird Ihnen dabei weiterhelfen können.
(8) Ist diese Checkbox gesetzt, dann finden Sie in (10) zusätzliche Trace-Meldungen.
(9) 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) Springt zum Bereich Allgemeine Meldungen des Control Centers.
Authorization Grants
Grant Type "Authorization Code"
(11) 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) 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) 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_data. 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) 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) 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) 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) 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) 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.