Using OAuth 2.0
You can now use OAuth 2.0 as an authentication method in the Celonis Platform, with this method preferred to API keys or application keys.
OAuth 2.0 is an industry-standard framework that allows different applications to securely interact with each other on behalf of users without sharing sensitive credentials. To enable this, you can create an OAuth client and then define the scopes assigned to that client. These scopes allow you to manage who or what has access to your Celonis Platform features such as Studio, User Provisioning, and audit logs. This is based on the security principle of least privilege, so that an OAuth client gets only the required privilege to perform a certain task and not more.
In addition to defined scopes, OAuth access tokens have a limited lifetime (15 minutes) and OAuth client secrets can be easily rotated. These feature increase their security, making OAuth 2.0 an enhanced authentication method compared to API keys or application keys.
To register an OAuth client and define its scope, see: Registering your OAuth client in Celonis Platform.
Transition from API keys and application keys to OAuth authentication
To support your transition from API keys and application keys to OAuth authentication, consider the following points:
Access risks when using API keys: API keys can fall into the wrong hands, leading to unauthorized access. For example, API keys can inadvertently get checked into source control systems, exposing the key to repository viewers and the source control history.
Rotating API keys: Rotating API keys can be a challenging task. Because API key values persist within the caller’s environment or software systems, timing the rotation to quickly release a key, generate a new one, and save the key while keeping production environments running can pose challenges.
Limiting API scope: Assigning limited scopes to API keys isn’t possible. API keys grant access to the API called in its entirety — an all-or-nothing access level. Defining access for a limited scope, such as read access only vs. write access, and other fine-grained access control measures are not available through API keys.
API keys linked to user accounts: API keys linked to user accounts become invalid when the user exits the organization. Some organizations use service accounts to counteract this measure, which opens up access risks and management overhead.