Celonis Product Documentation

Basic Authentication

To authenticate with the source system, the username and password provided in the data connection is encoded with Base64. This encoded string will be prefixed with "Basic" and sent to every request's Authorization header.

User inputs required in the data connection:

Header:

"Authorization: Basic bG9sOnNlY3VyZQ=="

Bearer Authentication

To authenticate with the source system, this token will be prefixed with "Bearer" and sent to every request's Authorization header.

User inputs required in the data connection:

Header:

"Authorization: Bearer token"

API Key Authentication

To authenticate with the source system, this API Key will be sent in the "x-api-key" header of every request.

API keys are created within an individual user profile in your Celonis Platform team, with the key’s permissions mirroring those of the user who created them.

User inputs required in the data connection:

For more information about creating API keys, see: API keys.

Header: "x-api-key: YOUR-API-TOKEN”

Application Key Authentication

(select API Key)

This is used when creating extractions from a Celonis API, such as when you want to use audit log, login history, and Studio adoption APIs.

Creating applications enables you to give access and permissions to any applications you create, either within your team or externally. Once created, an application must be granted the necessary permissions within your Celonis Platform. By default, applications are created without any permissions set.

For more information about creating Application Keys, see: Application keys.

AppKey XxxxxxAxxxxBxxxxCxxxXBBBB

i.e. “AppKey” followed by a blank and the AppKey itself.

OAuth2 (Authorization Code)

To authenticate with the source system, the client ID and client secret are passed to the authorization endpoint to request authorization to access the service resources in the browser (when saving the connection). If the user is authorized, an authorization grant is passed. Using this authorization grant an access token needs to be requested from the Get Token endpoint. The returned token is then used for all upcoming requests.

The grant type authorization_code is being used. The client credentials can be sent as a Basic Auth header (default) or via the request body.

User inputs required in the data connection:

For Access Token, we send a request to the Get Token Endpoint with content:

“grant_type: <GRANT_TYPE>”

“client_id: <CLIENT_ID>”

“client_secret: <CLIENT_SECRET>

→ There is no test connection option, because you will get redirect to the UI of the source system for authentication.

OAuth2 (Authorization Code + Refresh Token)

In order to authenticate with the source system, the client ID and client secret are passed to the authorization endpoint to request authorization to access the service resources in the browser (when saving the connection). If the user is authorized, an authorization grant is passed. Using this authorization grant, an access token needs to be requested from the Get Token endpoint. The returned token is then used for all upcoming requests. As the token in that connection scenario is limited to a certain period of time, a new one is automatically recreated after the old one expires using the refresh token.

The grant types authorization_code and refresh_token are being used. The client credentials can be sent as a Basic Auth header (default) or via the request body.

User inputs required in the data connection:

To refresh the Access Token, we send a request to the Get Token Endpoint with content:

“grant_type: refresh_token”

“refresh_token: <REFRESH_TOKEN>“

And with Header

(generated from client id and secret):

"Authorization: Basic bG9sOnNlY3VyZQ=="

→ There is no test connection option, because you will get redirect to the UI of the source system for authentication.

OAuth2 (Client Credentials)

To authenticate with the source system, the client ID and client secret are passed to the Get token endpoint to get an access token. The returned token is then used for all upcoming requests.

The grant type client_credentials is being used. The client credentials are sent via the request body (default) or they can be sent as a Basic Auth header if required.

User inputs required in the data connection:

–

For Access Token, we send a request to the Get Token Endpoint with content:

“grant_type: client_credentials”

“client_id: <CLIENT_ID>”

“client_secret: <CLIENT_SECRET>

OAuth2 (Resource Owner)

The client ID, client secret, username, and password are passed to the Get token endpoint to get an access token to authenticate with the source system. The returned token is then used for all upcoming requests.

The Grant Type password is being used. The client credentials are sent via the request body (default) or they can be sent as a Basic Auth header if required.

User inputs required in the data connection:

–

For Access Token, we send a request to the Get Token Endpoint with content:

“grant_type: password”

“username: <USERNAME>”

“password: <PASSWORD>”

“client_id: <CLIENT_ID>”

“client_secret: <CLIENT_SECRET>

Note: Client secret is used only if it is specified.

OAuth2 (JWT Bearer with Private Key)

In order to authenticate with the source system, a JWT assertion is generated using the selected signature algorithm using the private key (required in non-encrypted PKCS 8 syntax) and optionally the audience, subject and issuer. The JWT assertion is then sent to the Get Token endpoint. The returned token is used for all upcoming requests.

The respective Grant Type can be found in the API documentation of the system you want to connect to. The audience, Issuer, Subject Label, and Private Key provided in the data connection are encoded with Base64.

User inputs required in the data connection:

–

For Access Token, we send a request to the Get Token Endpoint with content:

“grant_type: <GRANT_TYPE>”

“client_assertion: <JWT_ASSERTION>”

→ the JWT_ASSERTION: is the assertion generated from the Private Key and the selected Signature Algorithm

OAuth2 via Proxy

The client ID, client secret, username, and password are passed to the Get token endpoint to get an access token to authenticate with the source system. The returned token is then used for all upcoming requests.

Client ID, client secret, username, and password provided in the data connection are encoded with Base64 into one string.

User inputs required in the data connection:

–

For Access Token, we send a request to the Get Token Endpoint with headers:

“content-type: <CONTENT_TYPE>”

“Authorization: <AUTH_STR>”

→ the AUTH_STR has the value of Base64 encoded credentials.

The encoded part is generated from Client ID, Client Secret, Username and Password.

Custom Authentication

The custom authentication type allows you to configure the authentication method based on your source system. This includes the following configurations: