Enterprise SSO
How OIDC SSO, email-domain routing, and just-in-time workspace membership work, including the current scope.
Single sign-on (SSO) lets users sign in to Epismo through their company's OpenID Connect (OIDC) provider. A workspace owner or admin registers the company domain and OIDC connection, verifies domain ownership, and completes a real login test before enabling it.
What is available now
- Epismo uses the domain of the work email entered in the normal sign-in form or passed to
epismo login --emailto route the user to the workspace's IdP automatically. - Sign-in completes only when the IdP returns a verified email whose domain matches the workspace's verified domain.
- When the verified email belongs to an existing Epismo user, Epismo adds the OIDC identity to that user. Otherwise, Epismo creates a user.
- Epismo adds the user to the workspace as a
Memberthrough just-in-time (JIT) provisioning when needed.
Required SSO and current limits
SSO can be enabled as an additional sign-in method or marked Required after domain verification and a successful login test. When required, workspace access needs current verified SSO evidence, including Web, CLI, and MCP credentials. Evidence expires at an absolute 12-hour deadline; refreshing or deriving credentials does not extend it. Web redirects to SSO, while CLI/MCP requests without evidence are denied and require sign-in again. Required SSO applies to owners too; email codes do not bypass it.
Disabling someone in the IdP does not immediately invalidate an existing Epismo session or SSO evidence. Remove the member in Epismo to revoke workspace-home access. SCIM, group sync, role mapping, multiple domains, and multiple OIDC connections remain unavailable. Explicit personal sharing has independent access semantics.
Sign-in flow
- The user enters their company email in the normal Epismo sign-in form or runs
epismo login --email <address>. - Epismo finds an enabled, verified SSO connection by email domain.
- Epismo redirects the user to the company's IdP.
- Epismo validates the OIDC response and verified email.
- Epismo resolves the identity by
issuerandsubject. If the identity is new, Epismo links it to the user with the same verified email or creates a new user. - Epismo creates a
Membermembership when needed. - Epismo returns the user to the workspace.
The email address is used to discover the connection and confirm domain eligibility. The OIDC identity itself is identified by the issuer and subject issued by the IdP, not by email.
Configure SSO
A workspace owner or admin can configure SSO. A workspace currently supports one company email domain and one OIDC connection.
Create an application in your IdP
Create a web application in the IdP and register this callback URL:
https://epismo.ai/api/auth/oidc/callbackEpismo uses Authorization Code Flow, PKCE (S256), state, and nonce, and requests these scopes:
openid email profileThe ID token must contain these claims:
| Claim | Required | Purpose |
|---|---|---|
iss |
Yes | Must match the configured issuer |
sub |
Yes | Stable identifier for the OIDC identity |
email |
Yes | Determines eligibility for JIT provisioning |
email_verified |
Yes | Epismo trusts the email only when this is true |
name |
No | Display name for a new Epismo user; the email local part is used otherwise |
Assign the appropriate people to the Epismo application in your IdP. Epismo also checks the verified email domain, but that check does not replace IdP application assignment.
Save the connection in Epismo
Open the target workspace and go to workspace settings → Single sign-on.
| Field | Value |
|---|---|
| Company email domain | A company-owned domain such as acme.com |
| Issuer URL | The HTTPS issuer that publishes OIDC Discovery; it must match exactly |
| Client ID | Client ID of the application created in the IdP |
| Client secret | Enter for a confidential client; leave empty for a public client |
Client secrets are stored encrypted and are not displayed again after saving. Leaving the field empty preserves an existing secret. Use the explicit remove option to delete a stored secret.
Verify domain ownership
Before domain routing can be enabled, Epismo verifies that the workspace controls the domain. After saving the SSO configuration, add the DNS TXT record shown in settings. For example:
Name: _epismo-challenge.acme.com
Value: epismo-domain-verification=<random-challenge>Some DNS providers expect only _epismo-challenge in the Name field. After DNS propagation, select Verify DNS record. The domain becomes Verified when Epismo can read the exact TXT value.
Verification follows these rules:
- One email domain cannot be registered to multiple workspaces at the same time.
- Shared email domains such as
gmail.comandoutlook.comcannot be registered. - Each configuration receives a random challenge.
- Changing the domain clears the old verification and issues a new challenge.
- Regenerate challenge invalidates the previous challenge and disables SSO until the new value is verified.
- Deleting and recreating the configuration requires a new challenge and verification.
Enable the connection
- Save the connection details.
- Add and verify the DNS TXT record.
- Select Test SSO login and complete the IdP login as an administrator.
- Return to settings, turn on Enable SSO, and save.
The connection cannot be enabled until both DNS verification and a real login test succeed. Changing the issuer, Client ID, Client secret, or domain invalidates the login test. Changing the domain also requires DNS verification again.
Troubleshoot DNS verification
Check that the TXT record uses the exact hostname and value shown in Epismo, DNS propagation has completed, and the same domain is not registered to another workspace. If your provider displays the value as multiple strings, joining them must produce the exact value shown in Epismo. An old record cannot verify a recreated configuration because its challenge changes.
User sign-in and JIT provisioning
When an enabled connection exists, submitting a matching work email automatically redirects the user to the company IdP. There is no separate SSO button to choose. In the CLI, epismo login --email <address> performs the same discovery; SSO continues in the browser, while addresses without SSO complete email-code login in the terminal. After authentication, the OIDC response must have a valid signature, issuer, audience, expiration, state, nonce, and PKCE exchange. The ID token must also contain email_verified: true, and its email domain must match the workspace's verified domain.
If SSO cannot complete, Epismo shows explicit options to retry SSO, send an email code, or use another email. It does not send a fallback code automatically.
Epismo resolves the identity by issuer and subject. If the identity is new, Epismo links it to the user with the same verified email or creates a user when no match exists. It then adds the user to the workspace as a Member when needed. SSO never promotes a user automatically to owner or admin.
External users are not JIT-provisioned through a nonmatching IdP domain. Adding membership separately does not bypass required SSO.
Existing accounts
The email entered before the redirect is used only to select the SSO connection. Account linking uses the verified email returned by the IdP. If that email belongs to an existing Epismo user, Epismo adds the OIDC identity to that user. A signed-in user can also link an OIDC identity explicitly. An identity already linked to another user cannot be reassigned.
Access when SSO is required
Signing in with Google or an email code can still identify the user, but does not satisfy required workspace SSO. Complete SSO before accessing that workspace, including as an owner. CLI/MCP credentials without current evidence are rejected, and refreshing them does not reset the evidence deadline.
To turn on Required SSO, complete a successful SSO test in the same browser within the previous 10 minutes.