Eigener Zugang

(3) Eigene Kennung, Eigenes Kennwort: Siehe Abschnitte Eigener Zugang (Ich zum Partner) und Eigener Zugang (Ich zum Partner).

(4) DATEVconnect online: Siehe Abschnitt DATEV OAuth2 Hybrid Flow für eine spezielle OAuth2-Variante von DATEV.

(5) Preemptive Anmeldung verwenden: Siehe Abschnitt Preemptive Authentication und (10).

(6) OAuth1.0 konfigurieren, OAuth2.0 konfigurieren, Generic Bearer Token: Es kann eine Authentifizierung per OAuth konfiguriert werden. Das Ziel ist dabei das manuelle (und initiale) Abholen eines Access Tokens (und gegebenenfalls auch eines Refresh Tokens). Siehe Abschnitte OAuth 1.0 (Client) und OAuth 2.0 (Client). Der empfangene Access Token wird dann intern im Kanal hinterlegt, siehe auch (9) und (7), und bei einem Request an den (Resource) Server verwendet. Hinweis: Sobald über die Buttons etwas eingetragen ist, ist OAuth aktiviert (erkennbar auch an einem dann erscheinenden Ausrufezeichen), d. h. wenn der Kanal als Client auftritt, initiiert er die Anmeldung am Server über den OAuth-Ablauf. Hinweis: In den Zusatzkennungen sieht man einen Access Token in einem Eintrag mit dem Namen SYS_HTTP_OAUTH2 (bzw. SYS_HTTP_OAUTH1) und einen Refresh Token in einem Eintrag mit dem Namen SYS_HTTP_OAUTH2_REFRESH. Siehe auch Funktion change OAUTH2 access token(a,b). Hinweis: Der Token wird per Default im Header Authorization übergeben. Möchte man den Token in einem anderen Header übergeben, kann man die Zusatzkennung SYS_HTTP_ALT_HEADER_ACCESS_TOKEN anlegen und diese dann im Kanal mit dem gewünschten Header belegen.

Ist ein Bearer Token zur Authentifizierung notwendig, aber der Server bietet keinen standardisierten OAuth-Ablauf an, um einen Token abzuholen, können Sie eine generische Methode definieren, um den Token zu erhalten. Siehe Abschnitt Generic Bearer Token (Client).

(7) OAuth2 Refresh URL: Ist hier ein gültige Refresh-URL eingetragen und es ist ein Refresh Token vorhanden, dann wird bei jedem HTTP-Zugriff über diesen Kanal automatisch ein neuer Access Token abgerufen (und im Kanal hinterlegt), falls (9) abgelaufen ist (bzw. schon 20 Sekunden davor). Dabei wird auch (9) neu gesetzt. Zudem wird dabei auch der Refresh Token aktualisiert. Verwenden Sie dazu die folgende URL: https://<server>/oauth/token?grant_type=refresh_token&refresh_token=<refreshToken>&client_id=<clientId>&client_secret=<clientSecret>

Es sind in der URL auch System-Konstanten erlaubt. Die entsprechenden Werte für die Platzhalter (siehe Tooltip in GUI) werden aus (6) entnommen oder wie bei <server> aus dem Feld "Partner-Adresse". Der Wert für <server> muss der Endpoint URL entsprechen, ersetzen Sie den Platzhalter also im Bedarfsfall in der URL manuell mit diesem Wert.

Hinweis: Sie können den Zusatz &useCredentialsInHeader angeben, damit die Credentials (client_id und client_secret) im Header statt im Body angegeben werden. Sie können den Zusatz &useJSON angeben, dann wird die HTTP-Methode POST verwendet mit Content-Type application/json. Alle Einträge &param=value in der Query werden dann zu {"param": "value", ...} umgebaut. In diesem Fall sollten die Werte auf keinen Fall URL-encoded sein!

Hinweis: Nicht alle Authorization Server liefern einen Refresh Token (ist optional). Beim Grant Type Client Credentials ist laut RFC sogar explizit kein Refresh Token vorgesehen. Wenn nun tatsächlich vom Authorization Server kein Refresh Token geliefert wird, funktioniert die oben angegebene URL natürlich auch nicht. Wenn nun der initial abgeholte, siehe Abschnitt OAuth 2.0 (Client), Access Token abläuft, kann man dieses Feld auch verwenden, um automatisiert erneut einen "initialen" Access Token abholen zu lassen. Beim Grant Type Authorization Code funktioniert das aber nicht, da Sie hier ja auf einer externen Seite manuell Zugangsdaten eingeben müssen. Verwenden Sie zu diesem Zweck folgende URLs (auswählbar über das %-Symbol rechts).

Client Credentials: https://<server>/oauth/token?grant_type=client_credentials&client_id=<clientId>&client_secret=<clientSecret>

Password Credentials: https://<server>/oauth/token?grant_type=password&client_id=<clientId>&client_secret=<clientSecret>&username=xxxxx&password=xxxxx

(8) Testen: Hier kann der Refresh (7) zu Testzwecken manuell ausgelöst werden. Siehe auch Funktion refresh OAUTH2 access token(a,b,c,d,e,f,g,h,i). Hinweis: Siehe auch https://www.rfc-editor.org/rfc/rfc6749#section-1.5 und https://www.oauth.com/oauth2-servers/making-authenticated-requests/refreshing-an-access-token/.

Unter-Dialog "Refresh Access Token":

(8.1) OAuth2 Refresh URL: Wird automatisch übernommen aus dem Hauptdialog.

(8.2) Ausführen: Klicken Sie hier, um den neuen Access Token (und Refresh Token) abzuholen.

(8.3) Ergebnis: Hier wird das Ergebnis der Abfrage angezeigt.

(8.4) Einstellungen übernehmen: Sie müssen hier klicken, damit der neue Access und Refresh Token auch wirklich vom Kanal übernommen werden (→ siehe Zusatzkennungen). Da es sich bei dem "Test" um einen echten Aufruf handelt, sollten Sie das auch tun, da sonst Ihr Access Token und Refresh Token im Kanal nicht mehr aktuell sind (da der Server die neu gelieferten erwartet). Hinweis: (9) wird dann ebenfalls aktualisiert.

(9) Access Token läuft ab am: Wurde über (6) oder (8) ein OAuth2 Access Token abgerufen, dann wird hier automatisch die Ablaufzeit eingetragen.

Partner-Zugang

(10) Partner Kennung, Partner Kennwort: Siehe Abschnitte Eigener Zugang (Ich zum Partner) und Partner-Zugang (Partner zu mir). Hinweis: Bei Verwendung von Basic Auth kann die Aktivierung der Checkbox (5) erforderlich sein, um Authentifizierungsinformationen bereits mit dem ersten HTTP-Request zu senden (Eigener Zugang).

(11) Partner-Kontakt: Siehe Abschnitt Partner-Kontakt.

(12) Zusatzkennungen: Siehe Abschnitt Zusatzkennungen (im Kanal).

(13) OAuth2: Wenn Lobster Integration als HTTP-Server auftritt, ist eine Authentifizierung des Clients per OAuth2 möglich. Siehe Abschnitt OAuth 2.0 (Server).

(14) OpenID: Authentifizierung über OpenID-Anbieter/Provider. Siehe Abschnitt OpenID (Server).