Single sign-on (SSO)
SAML 2.0 and OIDC config storage so an admin can wire a corporate identity provider against their tenant. Enterprise plan only.
SSO configuration lets an Enterprise tenant wire a corporate identity provider — SAML 2.0 or OIDC — against its workspace, with the configuration stored, the plan gate enforced, and every change recorded in the audit log.
This page is precise about scope: what is shipped today is configuration storage and governance. Login-time assertion verification is not part of this release.
Key points
- Stores IdP metadata only: entity id, SSO URL, cert (SAML) or issuer + client id + secret (OIDC).
- Supports an optional enforced_domain — when a login email matches the domain, the tenant must use SSO.
- OIDC client secret is write-only on the API: read endpoints return a presence indicator, never the raw value.
- Admin-only mutation: a non-admin gets a 403 even when the feature is allowed on the plan.
What is shipped
- Metadata storage and admin UI under /settings/sso.
- Plan-gate enforcement (Enterprise) at PUT time, with 402 PLAN_UPGRADE_REQUIRED for lower tiers.
- Audit log entry per upsert / delete so the IdP cutover is traceable.
Admins manage the configuration under /settings/sso. Plan enforcement happens at write time — a lower tier receives 402 PLAN_UPGRADE_REQUIRED — and each upsert or delete produces an audit entry, so an IdP cutover is traceable end to end.
What is not shipped yet
- Actual SAML assertion verification at login time — login still goes through password + Google OAuth.
- OIDC code exchange and JIT user provisioning.
- IdP-initiated login flow.
Not shipped yet: SAML assertion verification at login, OIDC code exchange with JIT provisioning, and IdP-initiated login. Signing in still uses password plus the existing providers, so SSO configuration today is preparation, not a live authentication path.
Related resources