Own ID

(3) Own ID, Own password: See sections Own ID (Me towards partner) and Partner ID (Partner towards me) .

(4) DATEVconnect online: See section DATEV OAuth2 Hybrid Flow for a special OAuth2 variant of DATEV.

(5) Use preemptive login: See section Preemptive Authentication and (10).

(6) Configure OAuth1.0, Configure OAuth1.0, Generic Bearer Token: This channel type allows OAuth authentication. The goal here is to manually (and initially) pick up an access token (and possibly also a refresh token). See sections OAuth 1.0 (client) and OAuth 2.0 (client). The received access token is then stored internally in the channel, see also (9) and (7), and used in a request to the (resource) server. Note : As soon as something is entered via the buttons, OAuth is activated (also recognisable by an exclamation mark appearing then), i.e. if the channel acts as a client, it initiates the logon to the server via the OAuth process. Note: You will find an entry with the name "SYS_HTTP_OAUTH2" (resp. "SYS_HTTP_OAUTH1") in the additional IDs for an access token and an entry with the name SYS_HTTP_OAUTH2_REFRESH for a refresh token. See also function change OAUTH2 access token(). Note: The token is transferred in the "Authorisation" header by default. If you want to transfer the token in a different header, you can create the additional ID SYS_HTTP_ALT_HEADER_ACCESS_TOKEN and then assign the desired header to it in the channel.

If a bearer token is required for authentication, but the server does not provide a standardized OAuth flow to retrieve a token, you can define a generic method to obtain the token. See section Generic Bearer Token (client).

(7) OAuth2 Refresh URL: If a valid refresh URL is entered here and there is a refresh token, a new access token is automatically retrieved (and stored in the channel) for each HTTP access via this channel if (9) has expired (resp. already 20 seconds before that). The expiration time (9) will be reset and the refresh token will also be updated. Use the following URL: "https://<server>/oauth/token?grant_type=refresh_token&refresh_token=<refreshToken>&client_id=<clientId>&client_secret=<clientSecret>".

You can also use system constants in the URL. The corresponding values for the placeholders (see tooltip in GUI) are taken from (6) or as for <server> from field "Partner address". The value for <server> must be like the " Endpoint URL". So replace the placeholder manually with this value in the URL if necessary.

Note: You can add "&useCredentialsInHeader" to the URL, for the credentials (" client_id" and " client_secret" ) to be specified in the header instead of the body. If you add "&useJSON" to the URL, the HTTP method POST with content type "application/json" is used. All entries "&param=value" in the query are then converted to "{"param": "value", ...}". In this case, the values should not be URL-encoded!

Note: Not all Authorisation Servers provide a refresh token (this is optional). According to the RFC, grant type Client Credentials shouldn't even provide one in any case. If the authorisation server does not provide a refresh token, the URL above will obviously not work. If, in this case, the initially fetched, see section OAuth 2.0 (client), access token expires, you can also use this field to automatically fetch another 'initial' access token. However, this does not work for the Grant Type Authorisation Code, as you have to enter access data manually on an external page. Use the following URLs for this purpose (selectable via the % symbol on the right).

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) Test: Here the refresh (7) can be triggered manually for test purposes. See also function refresh OAUTH2 access token(). Note: See also https://www.rfc-editor.org/rfc/rfc6749#section-1.5 and https://www.oauth.com/oauth2-servers/making-authenticated-requests/refreshing-an-access-token/ .

Sub dialogue "Refresh Access Token":

(8.1) OAuth2 Refresh URL: Is automatically taken over from the main dialogue.

(8.2) Execute: Click here to pick up the new access token (and refresh token).

(8.3) Result: The result of the query is displayed here.

(8.4) Apply settings: You must click here so that the new access and refresh tokens are actually taken over by the channel. (→ see additional IDs). Since the 'test' is a real call, you should in fact do this, otherwise your access token and refresh token in the channel will no longer be up-to-date (since the server expects the newly delivered ones). Note: (9) is then also updated.

(9) Access token expires on: If an OAuth2 access token was retrieved via (6) or (8), then the expiry time is automatically entered here.

Partner ID

(10) Partner ID, Partner password: See section Own ID (Me towards partner) and Partner ID (Partner towards me). Note: When using Basic Auth, it may be necessary to activate checkbox (5) in order to send authentication information with the first HTTP request (Own ID).

(11) Partner contact: See section Partner contact.

(12) Additional IDs: See section Additional IDs (in channel).

(13) OAuth2: If Lobster Integration acts as HTTP server, authentication of the client via OAuth2 is possible. See section OAuth 2.0 (server) .

(14) OpenID : Authentication via OpenID provider. See section OpenID (server) .