How identity works in Camunda
Camunda Self-Managed uses two separate identity subsystems.
Understanding which subsystem controls what helps you avoid a common misconfiguration — connecting your identity provider (IdP) to one system but not the other, so some components authenticate while others don't.
The two identity subsystems
| Subsystem | Governs | Controls |
|---|---|---|
| Management Identity | Camunda Hub (Console, Web Modeler), Optimize | Who can log in, organization/project membership, role assignments |
| Admin | Operate, Tasklist, Zeebe, Orchestration Cluster API (per cluster) | Who can log in, role assignments, machine-to-machine (M2M) credentials, fine-grained resource-level authorizations (for example, access to specific process definitions, decisions, or tasks) |
For the full breakdown, see Admin vs Management Identity.
In most deployments, both subsystems share the same IdP — you create a separate OIDC application registration for each subsystem but manage users in one place at the IdP level.
How identity changed in Camunda 8.8
Before Camunda 8.8, Management Identity (then called just Identity) managed access for every component, including Zeebe, Operate, and Tasklist. Camunda 8.8 split identity management into two subsystems. The Orchestration Cluster began managing its own authentication and authorization through Admin (formerly called Orchestration Cluster Identity). See Identity, authentication, and authorization for the full migration details.
Admin becomes the single source of truth for the migrated cluster's roles and authorizations after this change. Existing roles and authorizations carry over automatically during the upgrade, so nothing needs to be re-created. From that point on, manage access to Operate and Tasklist in Admin — role or authorization changes made in Console or Management Identity no longer apply to the migrated cluster.
Configure the identity subsystems
If you are deploying the full Camunda Self-Managed stack, you configure both subsystems, in this order:
- Management Identity first — configure your IdP connection and verify users can log in to Camunda Hub.
- Admin second — configure a separate IdP application registration and verify users can log in to Operate and Tasklist.
If you are deploying only the Orchestration Cluster (Operate, Tasklist, Zeebe) without the management plane, you only need to configure Admin.
For most full deployments, configure both Management Identity and Admin.
Key terms
| Term | Meaning |
|---|---|
| Client ID | The identifier your IdP assigns to an OIDC application registration. Camunda needs one per subsystem. |
| Client secret | The credential your IdP issues alongside the client ID. Treat it as a password. |
| Issuer URL | The base URL of your IdP's OIDC authorization server. Camunda uses this to discover token and JWKS endpoints. |
| Redirect URI | The URL Camunda registers with your IdP so the IdP knows where to send users after authentication. |
| Scopes | The OIDC permission sets Camunda requests from your IdP (typically openid profile email). |
| Claims | The fields in the ID token your IdP returns. Camunda reads specific claims (such as sub, email, preferred_username) to identify users. |
| JWKS endpoint | The URL your IdP exposes to publish its public signing keys. Camunda uses this to validate token signatures. |
Next steps
Connect Management Identity to an identity provider
Configure OIDC for Camunda Hub and Optimize.
Connect Admin to an identity provider
Configure OIDC for Operate, Tasklist, and the Zeebe API.