Identity and access management in Camunda 8
Use Identity access control to provide secure access for authorized users and systems in Camunda 8.
Identity types in Camunda 8
There are two types of Identity in Camunda 8.
| Orchestration Cluster Identity | Used for authenticating and authorizing users and systems that interact with the Orchestration Cluster (such as Zeebe, Operate, Tasklist, and the Orchestration Cluster REST API). Identity governs access to process execution, task management, and related runtime resources. |
| Management Identity | Used for managing the components Web Modeler, Console, and Optimize. Management Identity is typically required for platform administrators and developers, and is separate from the Identities used for process orchestration. |
Understanding which Identity is required for a given action helps you apply the correct access control policies.
Identity provider (IdP) integration
In production setups, both the Orchestration Cluster Identity and the Management Identity can integrate with an external OIDC IdP (such as Entra ID) for unified user management, single sign-on (SSO), and consistent security policies.
| Identity type | Description | Default IdP | External IdP support |
|---|---|---|---|
| Orchestration Cluster Identity | Built-in user management with support for external IdP integration via OIDC. Connects to enterprise IdPs such as Microsoft Entra ID, Okta, and more. | Built-in user management | OIDC integration with enterprise IdPs |
| Management Identity | Uses Keycloak by default, but can be configured with an external IdP via OIDC. | Keycloak | OIDC integration with external IdPs |
Authentication vs. authorization
Authentication and authorization are the two fundamental concepts for access control in Camunda 8.
Authentication
Authentication verifies who a user or system is.
Example: Logging in with a username/password or via SSO.
Authorization
Authorization determines what an authenticated user or system is allowed to do.
Example: Accessing Operate data, starting a process instance, or managing tasks.
| Identity type | Authorization model | Description | Management interface |
|---|---|---|---|
| Orchestration Cluster Identity | Fine-grained permissions | Controls access to applications, APIs, and resources through specific permissions for each resource type and action. | Camunda Identity UI or API |
| Management Identity | Role-based access control (RBAC) | Uses predefined roles and permissions for users and groups. | Keycloak admin console or external IdP |
How authentication and authorization work together
- Authentication happens first: The system verifies identity.
- Authorization happens next: The system verifies permissions.
A user must be both authenticated and authorized to access protected resources.
To learn more about authorization and how to configure permissions, see Orchestration Cluster authorization.
Authentication methods overview
Camunda 8 supports multiple authentication methods depending on the environment:
| Environment | Authentication method | Notes |
|---|---|---|
| Camunda 8 Run | None / Basic Auth / OIDC | No auth or basic auth only for local development. OIDC optional if configured. |
| Docker Compose | None / Basic Auth / OIDC | No auth or basic auth only for local development. OIDC optional if configured. |
| Helm Self-Managed | Basic Auth / OIDC | Basic Auth default, OIDC optional if configured. |
| SaaS | OIDC | OIDC required for all requests. |
- No authentication: only for local development (Run, Docker Compose).
- Basic authentication: simple to set up; not recommended for production.
- OIDC-based authentication: recommended for production Self-Managed and required for SaaS.
For API documentation, link to the centralized authentication overview instead of repeating environment defaults.
The Operate, Tasklist, and Zeebe REST APIs are deprecated. While they continue to function, new development should use the Orchestration Cluster REST API by referencing the Orchestration Cluster REST API migration documentation.
Authentication for all these APIs works the same way; see the Orchestration Cluster REST API authentication page for details.
How to obtain tokens
For environments using OIDC:
- Generate a JSON Web Token (JWT).
- Include it in each API request as:
Authorization: Bearer <TOKEN>.
Example request using a token:
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
${BASE_URL}/v1/process-instances/search
Token expiration
Tokens expire according to the expires_in field returned by the IdP. After expiration, request a new token.