DocsDeployment & OperationsAuthentication Setup
Loading documentation, please wait.
NEMORIONDocsNEMORIONDocsSovereign uses a platform-wide authentication service that handles login for all products. You choose one of three authentication modes based on your deployment needs, from zero-friction development to enterprise-grade single sign-on.
| Mode | Best For | What Users Experience |
|---|---|---|
| Bypass | Fresh deploys, single-operator air-gap, automated testing | No login required — everyone has access |
| Local | Deployments without an external identity provider | Email and password login for each registered user |
| OIDC | Production deployments with an existing IdP | Users log in with their existing corporate credentials (Okta, Azure AD, Google, etc.) |
Set the mode with a single configuration value:
Auth__Mode=Bypass
Auth__Mode=Local
Auth__Mode=Oidc
Only one mode is active at a time.
Bypass mode disables authentication entirely. Every request is accepted without credentials. The service starts and accepts all requests with no additional settings.
Configuration:
Auth__Mode=Bypass
When to use:
Bypass mode cannot be upgraded from once the deployment has data, and other modes cannot be downgraded to Bypass once any data is present. Choose Bypass only if you intend to operate the deployment in Bypass mode permanently, or for fresh deployments before any data is written.
Local mode uses an internal user store with passwords managed by Sovereign. The first admin account is created automatically from your environment settings; additional users are registered manually.
Configuration:
Auth__Mode=Local
Auth__Local__AdminUser__Email=admin@yourcompany.com
Auth__Local__AdminUser__Password=YourSecurePassword123!
Auth__Local__AdminUser__TenantId=default
| Setting | Required | Default | Description |
|---|---|---|---|
Auth__Local__AdminUser__Email | No | admin@local | Login email for the admin |
Auth__Local__AdminUser__Password | Yes | — | Admin password (minimum 12 characters) |
Auth__Local__AdminUser__TenantId | No | default | Tenant ID for the admin user |
Auth__Local__AdminUser__Roles__0 | No | admin | Roles assigned to the admin |
The admin password must be at least 12 characters. The service will not start with a weak or default password.
What users experience: A login page where they enter their email and password.
When to use: Any deployment that needs authenticated access without an external identity provider. Local mode supports any team size; every user must be registered manually (no automatic provisioning / SCIM). An upgrade path from Local to OIDC federation is in development and preserves existing user data; there is no planned downgrade path from OIDC back to Local.
OIDC mode connects to your company's identity provider, letting users log in with their existing corporate credentials. This is the recommended mode for all production deployments.
Configuration:
Auth__Mode=Oidc
Auth__Oidc__Authority=https://login.microsoftonline.com/{your-tenant-id}/v2.0
Auth__Oidc__ClientId=your-client-id
Auth__Oidc__ClientSecret=your-client-secret
Auth__Oidc__ApplicationBaseUrl=https://workflows.yourcompany.com
| Setting | Required | Default | Description |
|---|---|---|---|
Auth__Oidc__Authority | Yes | — | Your identity provider's discovery URL |
Auth__Oidc__ClientId | Yes | — | OAuth client ID from your IdP |
Auth__Oidc__ClientSecret | Yes | — | OAuth client secret from your IdP |
Auth__Oidc__ApplicationBaseUrl | Yes | — | Your deployment's public URL |
Auth__Oidc__CallbackPath | No | /auth/callback | OAuth redirect path |
Auth__Oidc__Scopes | No | openid, profile, email | Scopes to request |
Auth__Oidc__PostLogoutRedirectUri | No | — | Where to redirect after logout |
OIDC mode works with any standard OpenID Connect provider:
https://login.microsoftonline.com/{tenant-id}/v2.0https://{your-domain}.okta.comhttps://{your-domain}.auth0.comhttps://{host}/realms/{realm}https://accounts.google.com{your-deployment-url}/auth/callbackUser roles are mapped from your identity provider's claims. Ensure your IdP includes role information in the ID token or userinfo response so that role-based access control works correctly.
What users experience: Clicking "Login" redirects them to your company's familiar login page. After authenticating there, they are redirected back to Sovereign, fully logged in.
The Auth Service issues access tokens and refresh tokens for authenticated sessions. These settings control token behavior:
Auth__PlatformToken__Issuer=dataworkflows-engine
Auth__PlatformToken__Audience=sovereign-platform-internal
Auth__PlatformToken__AccessTokenExpirationMinutes=15
Auth__PlatformToken__RefreshTokenExpirationDays=7
Auth__PlatformToken__Audience defaults to sovereign-platform-internal — the single canonical audience claim for every Sovereign-internal platform JWT. Every consumer (Orbit API, Workflows Engine, MCP Server, etc.) validates against this exact value. Override only if you understand the implications for inter-service JWT validation across every consumer simultaneously.
Tokens are signed with an asymmetric key. For production:
Auth__PlatformToken__SigningKey__Source=File
Auth__PlatformToken__SigningKey__Path=/etc/sovereign/keys/signing.key
Pre-generate your signing key out-of-band and store it securely — a dedicated key management service, sealed secrets workflow, or equivalent.
Regardless of authentication mode, all data in Sovereign is scoped to tenants. Every authenticated request carries a tenant identity. The system enforces that users can only access workflows, executions, configurations, and connections within their own tenant. Cross-tenant access is not possible through the API.