OAuth 2.0
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(S) 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.
General Settings
(1) Will be entered automatically.
(2) 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.
(3) With this field you can pass additional free text (i.e. an additional free parameter). Example: Assume the field contains the value my_free_text. If (6) is not set, it looks like this in the request:
|
...&client_secret=my+secret&my_free_text |
If (6) is set, then it looks like this:
|
{ |
In both cases the free text must of course have a fitting syntax. Note: See also (8).
Furthermore, you can use the prefix header: to set an additional header. If you specify the value header:x-api-key=myvalue, for example, the header x-api-key is set with value myvalue. Please make sure not to use spaces before or after the equal sign. There is also no URL encoding of the value, i.e. if necessary, the value must already be entered URL-encoded.
(4) 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) The endpoint URL. After a successful Authorization Grant (4), the channel receives the Access Token from this URL of the Authorization Server.
(6) 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) 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 _data (Integration Server) can be reached from outside the internal network. Your network administrator will be able to help you with this.
(8) If this checkbox is set, you will find additional trace messages in (10).
(9) 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) Jumps to area General Messages of the Control Center.
Authorization Grants
Grant Type 'Authorization Code'
(11) 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) 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) 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_data. 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) 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) 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) 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) 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) 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.