Authentication & Authorization
Choose and configure authentication and authorization for Elsa Server, Elsa Studio, users, and API clients.
Authentication establishes who a caller is. Authorization determines what that caller may do. In an Elsa deployment, those decisions span Elsa Server, Elsa Studio, and any workflow endpoints exposed by the HttpEndpoint activity.
Use this section to choose an authentication topology and configure access to the Elsa API. Use Security & Hardening for secrets, workflow ingress, bearer-style resume URLs, TLS, rate limiting, and production controls.
Choose an authentication path
Elsa manages users, roles, tokens, and API applications
A service or automation client calls the Elsa API
Studio signs in directly with an upstream OpenID Connect provider
Elsa brokers one or more upstream providers and manages connections, identity links, and sessions
The host supplies another ASP.NET Core authentication scheme
Authentication must be disabled for an isolated local environment
External Authentication is available as of Elsa 3.8, which is currently under development. Preview packages are published through the Elsa Feedz.io feed; they are not stable releases.
Direct OpenID Connect and External Authentication are different topologies. External Authentication is the strategic successor for new deployments that need Elsa-managed provider connections and sessions. Direct OIDC remains supported throughout Elsa 3.x and is not formally deprecated in Elsa 3.8.
Understand the security boundaries
Elsa Server API
Elsa API endpoints authenticate through ASP.NET Core and authorize through Elsa permissions claims. Elsa Identity issues those claims from assigned roles. External schemes must provide them directly or map trusted upstream roles, groups, or scopes into them.
See Elsa API Permissions for the permission model, endpoint families, and starter role templates.
Elsa Studio
Studio is an API client, not a second authorization authority. Its selected authentication provider signs the user in and obtains credentials for Elsa Server. The server still decides whether each API operation is allowed.
A successful Studio login therefore does not guarantee access to workflow definitions, instances, designer metadata, or administration screens. Missing permissions normally surface as 403 Forbidden responses from the API.
Workflow HTTP endpoints
Routes exposed by the HttpEndpoint activity have their own Authorize and Policy settings. They are separate from Elsa API permissions. A public workflow route does not make /elsa/api/* public, and API permissions do not secure a workflow route automatically.
Recommended reading paths
For an Elsa-managed deployment:
Configure Elsa Identity.
Define least-privilege roles with Elsa API Permissions.
Add API keys for service clients when needed.
Complete the production hardening checklist.
For an external identity provider:
Choose Direct OpenID Connect or External Authentication.
Configure the Elsa API permission claims required by Studio and operators.
Review provider secrets, redirects, TLS, and deployment controls under Security & Hardening.
Related sections
Last updated