Single sign-on
Route sign-in for your company's email domains through your own identity provider with enterprise SAML SSO.
Single sign-on delegates Carbon authentication to a SAML 2.0 , such as Okta, Entra ID, or Google Workspace. After you verify an email domain through DNS, Carbon routes ERP and MES users on that domain to the identity provider automatically. and other sign-in methods remain available until you enable Require SSO.
Requirements
SSO is an Enterprise Edition (EE) feature of your own self-hosted deployment (CARBON_EDITION=enterprise, which requires a commercial license). Carbon Cloud sign-in is unaffected. Enable it through environment variables:
sso to the comma-separated list of sign-in methods.openssl command is in .env.example.Connect your identity provider
Everything lives on one screen: Settings → Security, under "Single Sign-On" (viewing needs settings view; saving needs settings update).
Copy Carbon's service provider details. The "Service Provider Details" card shows the "ACS URL" and "SP Metadata URL" with copy buttons.
Register Carbon in your IdP as a SAML application using those two URLs. The assertion must include an email attribute; the email is how Carbon matches each sign-in to a person and a company.
Paste the IdP metadata back into Carbon. In the "Identity Provider" card, provide the "IdP Metadata URL" or the raw "IdP Metadata XML" (exactly one), then "Save". The card gaining a "Require SSO" switch and a "Deactivate" button is the sign the connection is active.
Verify your email domains. The "Email Domains" card appears once the connection exists. Add each domain your people sign in with, publish the DNS record it shows, and click "Verify". Only verified domains route SSO sign-ins.
Verifying a domain
Each added domain starts Pending with a unique TXT challenge shown on the card:
| Record | Value |
|---|---|
| Host | _carbon-challenge.example.com |
| Type | TXT |
| Value | carbon-domain-verification=<your unique token> |
Publish the record at your DNS host, click "Verify", and on a match the domain flips to Verified. Verification is one-time; the TXT record can be deleted afterwards. A Pending domain has no effect anywhere, so adding one is always safe.
Verified claims are exclusive
Only one company can hold a domain verified, first to prove DNS control wins, and the claim survives even if DNS control later changes hands. The clean handover is for the holding company to Remove the domain, which frees it for the new owner to verify.
How sign-in works
On the email-first login page, selecting "Continue" either redirects the user to the domain's active IdP or continues to the standard magic-link flow. Before creating a session, Carbon requires the asserted email domain to match a verified domain on the connection.
SSO provisioning is invite-first; it does not support self-service signup. An existing member's first SSO login links the SAML identity to their account. A pending invite is accepted during the first SSO login and applies its assigned role. Carbon rejects all other users without provisioning an account. Create their invite in the employees directory, then retry.
Requiring SSO
The "Require SSO" switch makes the IdP the only permitted authentication method for verified domains. Carbon rejects magic links, Google, Outlook, and passkeys server-side. The switch appears only for an active connection, allowing you to verify sign-in before enforcement. Turning it off restores other methods. "Deactivate" deletes the connection, releases its domain claims, and also restores other methods.
Break-glass recovery
If enforcement is on and your IdP is unreachable, nobody on the covered domains can sign in to turn it off. Operators can lift it directly in the database, and magic-link sign-in works on the next attempt:
UPDATE "ssoConnection" SET "requireSso" = false WHERE "companyId" = '<id>';SSO sessions bypass Carbon's two-factor challenge, including in controlled deployments, because the IdP enforces its own MFA policy. Magic-link logins still use Carbon's challenge.