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
Camunda 8 manages access in two separate places: one for Camunda Hub and Optimize, and one for each Orchestration Cluster.
These identities serve different purposes. One controls access to process execution and runtime APIs, while the other controls access to management and modeling components.
| Orchestration Cluster Admin (formerly 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). Admin governs access to process execution, task management, and related runtime resources. Each cluster has its own Admin, and what you configure there applies to that cluster only. |
| Organization access (Camunda Hub and Optimize) | Used for managing who can use Camunda Hub and Optimize, and what permissions they have. It is separate from the access you configure in Admin. In SaaS, you manage organization access in Camunda Hub, from the Organization management view. In Self-Managed, Management Identity provides organization access. Management Identity is a Self-Managed-only component. |
Identity object identifiers and names are limited to 256 characters. This limit applies independently of the secondary storage backend used by the Orchestration Cluster.
Find out which identity you are configuring
The screen you are working in tells you which identity you are configuring.
| You are in | You are configuring | Edition |
|---|---|---|
| Organization management | Organization access: who can use Camunda Hub and Optimize, and their organization roles. | SaaS |
| Management Identity | Organization access: who can use Camunda Hub and Optimize, and their roles. | Self-Managed |
| Orchestration Cluster Admin | Access to a deployment environment, its runtime applications (Operate, Tasklist, Admin, and Zeebe), and the Orchestration Cluster REST API. | SaaS and Self-Managed |
Identity provider (IdP) integration
In production setups, you can connect both Orchestration Cluster Admin and organization access to an external IdP (such as Entra ID) for unified user management, single sign-on (SSO), and consistent security policies. See connect to an identity provider.
| Identity type | Edition | Description | Default IdP | External IdP support |
|---|---|---|---|---|
| Orchestration Cluster Admin | SaaS and Self-Managed | 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 |
| Organization access (Camunda Hub) | SaaS | Organization-wide sign-in to Camunda Hub, managed by Camunda. | Auth0 | SAML or Microsoft Entra ID (organization SSO) |
| Organization access (Management Identity) | Self-Managed | 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 client is. For example, you log in with a username and password or through SSO.
Authorization
Authorization determines what an authenticated user or client is allowed to access in Camunda 8 and which actions they can perform on those resources.
For example, a user's authorizations allow them to access Operate, view running or completed process instances, start new process instances, or claim and complete user tasks in Tasklist and through the Orchestration Cluster REST API.
| Identity type | Authorization model | Description | Management interface |
|---|---|---|---|
| Orchestration Cluster Admin | Fine-grained permissions | Controls access to applications, APIs, and runtime resources through specific permissions for each resource type and action (for example, PROCESS_DEFINITION and USER_TASK). | Camunda Admin UI or API |
| Organization access (Camunda Hub, SaaS) | Role-based access control (RBAC) | Uses predefined organization roles to manage access to Camunda Hub and Optimize. | Camunda Hub: Organization > Manage organization |
| Organization access (Management Identity) | Role-based access control (RBAC) | Uses predefined roles and permissions for users and groups to manage Camunda Hub and Optimize in Self-Managed. | Management Identity, 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.
Authentication methods
Camunda 8 supports multiple authentication methods depending on the environment:
| Environment | Authentication method | Notes |
|---|---|---|
| Camunda 8 Run | None / Basic authentication / OIDC | No auth or Basic authentication only for local development. OIDC optional if configured. |
| Docker Compose | None / Basic authentication / OIDC | No auth or Basic authentication only for local development. OIDC optional if configured. |
| Helm Self-Managed | Basic authentication / OIDC | Basic authentication 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 and should not be used for new development. 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 these APIs works the same way. See Orchestration Cluster REST API authentication for details.
Users and clients
Actions in an orchestration cluster can be executed by two kinds of authenticated entities (also known as principals): users and clients. Users typically interact with the cluster through a browser, while clients interact programmatically through the APIs.
Although both principal types can use web UIs and APIs, the distinction still matters. Users represent individuals who are granted access to an orchestration cluster, whereas clients represent systems or applications.
If you're using Basic authentication to secure your cluster, both users and clients are treated as users. There is no dedicated client concept in this configuration.
Distinguishing between users and clients aligns your access management with how identities are modeled in your identity provider. They are usually authenticated differently (for example, username and password for users versus a client certificate for applications), have different authorization requirements (such as administrator access versus deployment permissions). Separating them simplifies auditing and operational clarity.
How to obtain tokens
For environments using OIDC:
- Generate a JSON Web Token (JWT).
- Include the token in each API request as:
Authorization: Bearer <TOKEN>.
Example request using a token:
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
${BASE_URL}/v2/process-instances/search
Token expiration
Tokens expire according to the expires_in field returned by the IdP. After expiration, request a new token.