OAuth 2.0 (Server)
If Lobster_data acts as HTTP server, authentication of the client via OAuth2 is possible. Can be turned off in configuration file ./etc/startup.xml with entry <Set name="enableOAuth">false</Set>.
The access token is valid for 30 days. Can be changed with system property hub.datawizard.oauth.expiresIn=<number_of_seconds>.
|
Grant type |
Description |
|
client_credentials |
Here the client only needs the Client ID (14) and Client Secret (15). The Client ID is the channel ID. The client secret is based on the partner password, so the partner password has to be set. If it changes, the Client Secret changes as well. Note: Instead of the Client Secret, the partner password can also directly be used for this grant type by the client. |
|
authorization_code |
The web page via which the credentials must be entered on the client side is located under ./webapps/root/oauth2/OAuth2.html. The credentials are partner ID and partner password. |
Token endpoint: <IP/URL of Integration Server>/dw/register/oauth/token
Authorization endpoint: <IP/URL of Integration Server>/dw/register/oauth/authorize
Redirect URI/Callback URL: <IP/URL of Integration Server>/dw/register/oauth/verify (only needed for authorization code flows)
Note: If a DMZ server is used, then the setup shown here remains identical on the inner Lobster_data, but the URLs involved must be entered in configuration file ./etc/forward.properties on the DMZ server.
/dw/register/oauth/token=<URL of inner Integration Server>/dw/register/oauth/token/dw/register/oauth/authorize=<URL of inner Integration Server>/dw/register/oauth/authorizeView after Successful Token Query
If a token has been requested, you see this extended view with the currently valid access token (1), the expiration time (2) and the refresh token (3).
Via (4) you can delete these entries again and restore the original state.