Single sign-on
Route sign-in for your company's email domains through your own identity provider with enterprise SAML SSO.
Single sign-on hands control of Carbon sign-in to your own : Okta, Entra ID, Google Workspace, or any SAML 2.0 IdP. Register your email domains once, proving you own each with a DNS record, and everyone on them signs in to both ERP and MES with their normal work email — Carbon recognizes the domain and routes to your IdP automatically, no SSO button to find. Registering takes nothing away: the and other methods keep working until you turn on Require SSO.
Requirements
SSO is an Enterprise 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
The login page is email-first and the SSO fork is invisible: the user types their email, presses "Continue", and Carbon either redirects to your IdP (active connection on that domain) or falls through to the ordinary magic-link flow. Before any session is created, the asserted email's domain must be one of the connection's verified domains, so even a misconfigured or hostile IdP can't sign someone into another company.
Provisioning is invite-first: no self-serve signup through SSO. An existing member signs straight in (their first SSO sign-in quietly links the SAML identity to their account; the magic link keeps working). Someone with a pending invite has it accepted by their first SSO sign-in, landing with exactly the invite's role. Anyone else is rejected by name and nothing is provisioned; create the invite in the employees directory and the retry just works.
Requiring SSO
Once a sign-in has worked, the "Require SSO" switch on the Identity Provider card makes the IdP the only way in for verified domains: magic links, Google, Outlook, and passkeys are all refused server-side. The switch exists only on an active connection, so the path is always set up, prove a sign-in works, enforce last. Turning it off — or "Deactivate", which deletes the connection and releases the domain claims — immediately restores the 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 skip Carbon's two-factor challenge and the company-wide requirement in every environment, including controlled (ITAR) deployments: your IdP already enforced its own MFA policy at sign-in. Magic-link logins still get Carbon's own challenge.