Sovereign Platform is in pre-launch alpha.
Not yet available to purchase. Sign up for our mailing list for upcoming launch dates.
Loading documentation, please wait.
Sovereign Platform is in pre-launch alpha.
Not yet available to purchase. Sign up for our mailing list for upcoming launch dates.
Sovereign 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 | Development and testing | No login required — everyone has access |
| Local | Small teams and getting started | A single admin account with email and password |
| OIDC | Production deployments | 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. This is the fastest way to get started and is the default for development environments.
Development Only
Bypass mode provides no security. It is automatically blocked in production environments. Never use it for deployments that handle real data.
Configuration:
Auth__Mode=Bypass
No additional settings are needed. The service starts and accepts all requests.
When to use: Local development, initial deployment testing, and automated test environments where authentication is not the focus.
Local mode provides a single built-in admin account. You configure the email and password in your environment settings, and the account is created automatically on first login.
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 |
Password Requirements
The admin password must be at least 12 characters. The service will not start with a weak or default password in non-development environments.
What users experience: A login page where they enter the admin email and password.
When to use: Small single-operator deployments, development environments where you need a real user identity for testing, and air-gapped deployments without an external identity provider.
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/callbackRole Mapping
User 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=dataworkflows-api
Auth__PlatformToken__AccessTokenExpirationMinutes=15
Auth__PlatformToken__RefreshTokenExpirationDays=7
Tokens are signed with an asymmetric key. For production:
Auth__PlatformToken__SigningKey__Source=File
Auth__PlatformToken__SigningKey__Path=/etc/sovereign/keys/signing.key
Auth__PlatformToken__SigningKey__GenerateIfMissing=false
Production Key Management
Set GenerateIfMissing to false in production. Pre-generate your signing key and store it securely. Auto-generation is only appropriate for development.
For development, you can allow auto-generation:
Auth__PlatformToken__SigningKey__GenerateIfMissing=true
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.