This API is documented in OpenAPI format.

Several API operations require an authenticated user. Intershop ICM REST API supports authentication using:

• token endpoint (supports password grant, refresh-token grant, client-authentication grant via basic authentication or bearer token)
• basic authentication
• header authentication-token

Tokens are encoded or signed strings that can be used to authenticate a REST request. Tokens are submitted using the header Authorization containing the word Bearer followed by space and the token string. Alternatively the header authentication-token containing the user token can be used.

The token endpoint is used to create tokens that are used in subsequent requests as authentication token. The user can authenticate using:

• username and password
• anonymous user
• basic authentication
• refresh token The response will contain a set of tokens that should be used to authenticate subsequent requests. Along with ID- and access-tokens a refresh token is returned. Use the received refresh token to renew expired tokens to authenticate further requests. Along with the token expiration times are given in the token set response. ID and access tokens cannot be used after this expiration time.

Every REST endpoint supports authentication using basic authentication. To authenticate the client sends the users credentials with the header Authorization that contains the word Basic followed by space and a base64-encoded string username:password. The response of such a request includes a header authentication-token containing the user token. If the server does not support JWT (JSON Web Token) each response of REST request will contain the header authentication-token which should replace former tokens since it contains an updated expiration time.

Note: REST endpoints that support Web-Adapter-cached responses cannot be used for implicit token creation.
If the server supports JWT token as user token implicit token creation should not be used because the token will not renew.

This API can be used to create access and identity tokens which allow clients to securely call protected APIs. Clients request tokens that can be used in the 'Authorization' header so the server grants access to a particular resource which will be invoked in the context of the encoded user-identity.

• Client logs in a user with name and password. The client uses the received ID-token for subsequent requests and stores the refresh-token for further use:

  curl http://<SERVER>/INTERSHOP/rest/WFS/<SITE>/-/token -X POST -d "grant_type=password&username=<USERNAME>&password=<PASSWORD>&organization=<ORGANIZATION>" 

• The client renews the ID-token using the refresh-token if its expired or about to expire: Creates a set of token based on a refresh token:

  curl http://<SERVER>/INTERSHOP/rest/WFS/<SITE>/-/token -X POST -d "grant_type=refresh_token&refresh_token=<REFRESH_TOKEN>

• The client logs out the user (this will expire refresh-tokens):

  curl http://<SERVER>/INTERSHOP/rest/WFS/<SITE>/-/logout -X PUT -H "Authorization:Basic <REFRESH_TOKEN>"

Identity providers are used to authenticate users. Clients can use this endpoint in order to receive all identity providers that are available for an organization. Typically, this information can be used to enable a user to log on to the ICM back office or the storefront. There might be different types of identity providers. The type local is used for the standard internal ICM user login handling which is most often represented by a login form and completely handled by ICM server. However, other types include oidc for OpenID Connect compatible providers which can be used for single sign-on scenarios.

The following example shows how to retrieve identity providers for organization Operations:

curl https://<SERVER>/INTERSHOP/rest/WFS/<SITE>/-/identityproviderconfigurations/Operations