Overview
Experio uses PropelAuth BYO (a self-hosted sidecar) for enterprise Single Sign-On. It supports OIDC-based authentication with Microsoft Entra ID, Okta, and any Generic OIDC-compatible identity provider. PropelAuth acts as the source of truth for SSO client configuration — Experio’s admin panel manages SSO clients by syncing them with the PropelAuth sidecar via its integration API. Navigate to Admin > Users > SSO Clients to manage SSO configurations.Prerequisites
Before configuring SSO, ensure you have:- A running Experio deployment with the PropelAuth BYO sidecar container
- Admin access to the Experio admin panel
- An identity provider account (Microsoft Entra ID, Okta, or any OIDC-compatible provider)
- The redirect/callback URL for your deployment:
https://<your-domain>/api/auth/sso/callback
PropelAuth First-Time Setup
Before configuring SSO clients, you must set up PropelAuth BYO and obtain an integration API key.Automated Setup (Default)
The default deployment automatically creates the PropelAuth API key during initialization. To enable this, set the PropelAuth Setup Secret (propelauthSetupSecret) deployment parameter when creating or updating your Experio instance. This is the only configuration needed — everything else is handled automatically.
The automated setup works as follows:
- You provide the
propelauthSetupSecretdeployment parameter (must be at least 16 characters). This sets theINITIAL_SETUP_SECRETenvironment variable on the PropelAuth BYO container. - During deployment, the
setup_propelauthmanagement command calls the PropelAuth/api/initial_setupendpoint with this secret. - The returned API key is automatically stored as
PROPELAUTH_API_KEYin system settings.
The automated setup only works for the first API key creation. If you need to recreate the key, use the manual method below.
Manual Setup (Fallback)
If automated setup is not available or fails, follow these steps:- Access the cluster where Experio is deployed.
- Forward the PropelAuth port to your local machine:
- Open the PropelAuth dashboard at
http://localhost:2884. Log in with the default credentials:- Username:
root - Password:
thispasswordistemporary
- Username:
- Create a new password when prompted. Save this password securely.
- Create an integration API key: Click the gear icon, then go to Manage Settings and select the Integration Keys tab. Create a new key with
FullAccesspermissions. - Save the API key in Experio: Navigate to Admin > Settings > System Settings > AUTH and set
PROPELAUTH_API_KEY. See System Settings for details.
System Settings
Navigate to Admin > Settings > System Settings > AUTH tab to configure SSO behavior. See System Settings for the complete reference.Identity Provider Setup
Before creating an SSO client in Experio, register an application in your identity provider.Microsoft Entra ID (Azure AD)
-
Register an application in the Azure Portal:
- Navigate to Microsoft Entra ID then App registrations then New registration.
- Name the application (e.g., “Experio SSO”).
- Select Accounts in this organizational directory only (single tenant).
- Set Redirect URI type to Web and enter:
https://<your-domain>/api/auth/sso/callback
-
Copy credentials from the app’s Overview page:
- Application (client) ID — used as
client_id - Directory (tenant) ID — used as
tenant_id
- Application (client) ID — used as
-
Create a Client Secret:
- Go to Certificates & secrets, then Client secrets, then New client secret.
- Set a description and expiration period.
- Copy the secret Value immediately (it is shown only once).
-
You will need these three values when creating the SSO client in Experio:
client_id(Application ID)tenant_id(Directory ID)client_secret(Secret Value)
Okta
- Go to Okta Admin Console, then Applications, then Create App Integration.
- Select OIDC - OpenID Connect and Web Application.
- Set the Sign-in redirect URI to
https://<your-domain>/api/auth/sso/callback. - Note your Client ID, Client Secret, and Okta domain (e.g.,
dev-12345.okta.com).
Generic OIDC
For any OIDC-compatible provider, collect these values:
Set the redirect URI in your provider to
https://<your-domain>/api/auth/sso/callback.
Supported Identity Providers
Creating SSO Clients
Navigate to Admin > Users > SSO Clients and click Create New.Basic Information
- Email Domains: One or more domains this SSO applies to (e.g.,
acme.com,acme.io). Users with any of these email domains will be redirected to SSO login. Type each domain and press Enter to add it. Leave empty to allow all domains — the SSO client becomes a catch-all that any email can use. At most one active SSO client can have empty email domains at a time. - Display Name (required): Human-readable name (e.g., “Acme Corporation”).
- Identity Provider Type (required): Microsoft Entra ID, Okta, or Generic OIDC.
Identity Provider Credentials
- Client ID (required): From your IdP app registration.
- Client Secret (required): From your IdP.
- Tenant ID (Microsoft Entra only): Azure Directory/Tenant ID.
- SSO Domain (Okta only): Your Okta domain (e.g.,
dev-12345.okta.com). Enter just the domain, not a full URL — thehttp://prefix is automatically stripped if provided. - Auth URL, Token URL, UserInfo URL (Generic OIDC only): The OIDC endpoint URLs from your provider.
Review and Confirm
- Review the configuration summary.
- The Redirect URL is displayed (auto-generated as
https://<your-domain>/api/auth/sso/callback). - This redirect URL must match what you configured in your identity provider.
The Customer ID is automatically generated from the first email domain with a unique suffix (e.g.,
acme.com becomes acme-com-a1b2c3d4). For allow-all clients with no email domains, the ID uses the format allow-all-a1b2c3d4. Customer IDs are immutable after creation.Activating SSO
Follow these steps carefully to enable SSO without losing admin access:- Create a fallback admin user: Before enabling SSO, ensure you have a local admin user with the same email domain as the SSO client. Set this user as a superuser so you retain access if SSO has issues.
-
Enable SSO: Set
USE_PROPELAUTHtoTruein Admin > Settings > System Settings > AUTH. -
Enable hybrid login (recommended during testing): Set
ALLOW_HYBRID_LOGINtoTrueto keep password login available as a fallback. - Test SSO: Open a new incognito/private browser window, navigate to the login page, enter an email for the configured domain, and verify the SSO redirect works correctly.
-
Disable hybrid login (optional): Once SSO is confirmed working, set
ALLOW_HYBRID_LOGINtoFalsefor SSO-only login.
How SSO Login Works
- User navigates to the Experio login page.
- The login page shows an email-only form (SSO-only mode) or both password and SSO options (hybrid mode).
- User enters their email and submits.
- Experio extracts the email domain and looks up the matching SSO client.
- If no domain-specific match is found, Experio checks for an active “allow all domains” SSO client as a fallback.
- If a matching active SSO client is found (either by domain or fallback), PropelAuth initiates an OIDC login flow.
- The user is redirected to their identity provider’s login page (e.g., Microsoft login).
- After authenticating, the IdP redirects back to Experio’s callback URL.
- PropelAuth completes the OIDC flow and extracts user information.
- Experio creates or updates the user account. If
PROPELAUTH_SSO_USERS_ACTIVE_BY_DEFAULTisFalse, new users are created inactive and see a “pending administrator approval” message instead of being logged in. - Active users are redirected to Experio with an active session.
SSO users are automatically provisioned on first login. The
PROPELAUTH_SSO_USERS_ACTIVE_BY_DEFAULT setting controls whether they are immediately active or require admin approval.Managing SSO Clients
Viewing
The SSO clients page shows a table with Display Name, Email Domains, IdP Type, Active Status, and Created dates. Clients with no email domains display an “Allow all domains” badge.Editing
Click any SSO client to view and edit its configuration. You can clear all email domains to make the client an “allow all” catch-all — the detail page shows an “Allow all domains” badge in this state. Changes take effect immediately for new login attempts.Client secrets are never displayed after creation for security. To update a client secret, enter the new value in the edit form.