Simplified context

Basically we want to receive data (Resources) from an HTTP(S) server (Resource Server) with our channel (Client).

Therefore we need an Access Token, which we receive from an Authorization Server in advance. The Access Token is stored internally in the "HTTP" channel.

The following mask is only about how we get this Access Token. For this purpose, you first need an Authorization Grant.

Note: See also https://tools.ietf.org/html/rfc6749#section-1.1.

Settings

(1) Application ID: Will be entered automatically. Example: "_data1606366806421015".

(2) Scope: OAuth 2.0 scopes provide a way to limit the amount of access that is granted to an Access Token. For example, an Access Token issued to a client application may be granted read and write access to protected resources, or just read access. Note: The input of individual values can be completed with the Enter key. However, you can also enter several values at once, each separated by a space.

(3) Optional settings: Additional parameters (query or body) and headers can be specified here.

(4) Grant type: There are several methods (Authorization Code, Client Credentials, Password Credentials) with which you can get an Authorization Grant . See the corresponding subsections. Note: See also https://tools.ietf.org/html/rfc6749#section-1.2 .

(5) E ndpoint URL : The endpoint URL. After a successful Authorization Grant (4), the channel receives the Access Token from this URL of the Authorization Server. Example: "https://some-server/oauth/token".

(6) JSON request: If the checkbox is set, the body of all requests is sent in JSON format with content type application/json, otherwise with content type application/x-www-form-urlencoded.

(7) Redirect URL: Is automatically entered and only active for value Authorization Code in (4), see corresponding section below. Note: The IP may have to be adjusted if your Authorization Server is not in your internal network. I.e. you must then enter the IP with which your Lobster Integration (Integration Server) can be reached from outside the internal network. Your network administrator will be able to help you with this. Example: " https://192.168.132.193/dw/oauth2/_data1606366806421015 ". Example for "OAuth URL": " https://some-server/oauth/authorize ".

(8) Trace/Debug: If this checkbox is set, you will find additional trace messages in (10).

(9) Fetch access token: Click here to fetch the Access Token via the Token Endpoint URL (5) of the Authorization Server. Note: You will find an entry with the name SYS_HTTP_OAUTH2 in the additional IDs for the access token and an entry with the name SYS_HTTP_OAUTH2_REFRESH for a refresh token.

(10) Logs general messages: Jumps to page "General messages" of the Control Center.

Authorization grants

Grant type "Authorization Code"

(11) Client ID, Client secret: The Client ID is a public identifier for applications (here our channel). The Client Secret is only known to the Client and the Authorization Server. Note: Both are generated and provided by the Authorization Server in advance.

(12) Send client credentials in header: If this checkbox is set, the credentials ("Client ID", "Client Secret") are specified in the header instead of the body of the request to the Authorization Server.

(13) OAuth URL: The Authorization Endpoint URL. This URL of the Authorization Server will take you to a page where you can manually enter access data (for the Resource Server, which is finally validated by the Authorization Server). Via (7) you get back to Lobster Integration. By doing so, you will (simplified described) receive the Authorization Grant from the Authorization Server and then the Access Token (and possibly a Refresh Token). Note: See also https://tools.ietf.org/html/rfc6749#section-4.1.

Grant type "Client Credentials"

(14) Client ID, Client secret: The "Client ID" is a public identifier for applications (here our channel). The "Client Secret" is only known to the Client and the Authorization Server. Note: Both are generated and provided by the Authorization Server in advance.

Both are sent to the Authorization Server. This will get you the Authorization Grant and then the Access Token . Note: See also https://tools.ietf.org/html/rfc6749#section-4.4.

(15) Send client credentials in header: If this checkbox is set, the credentials (Client ID, Client Secret) are specified in the header instead of the body of the request to the Authorization Server.

Grant type "Password Credentials"

(16) Client ID, Client secret: The Client ID is a public identifier for applications (here our channel). The Client Secret is only known to the Client and the Authorization Server. Note: Both are generated and provided by the Authorization Server in advance. Important note: Both fields are not mandatory in this case, but some Authorization Servers require them!

(17) Send client credentials in header: If this checkbox is set, the credentials (Client ID, Client Secret) are specified in the header instead of the body of the request to the Authorization Server.

(18) Own ID, Own password: If you got access data from the Resource Server in advance, you can use it to obtain the Authorization Grant from the Authorization Server (which validates the access data for the Resource Server) and then the Access Token (and possibly a Refresh Token). See also (16). Note: See also https://tools.ietf.org/html/rfc6749#section-4.3.

DATEV OAuth2 Hybrid Flow

See section DATEV OAuth2 Hybrid Flow for a special OAuth2 variant of DATEV.