SSO / SAML Is Now Live for Enterprise Customers
SSO / SAML Is Now Live for Enterprise Customers
Release: v1.0.141
Enterprise plan customers can now authenticate their entire team through a corporate Identity Provider (IdP) using the SAML 2.0 protocol. This feature was listed on the Enterprise pricing tier from day one and is now fully implemented in the platform.
Background: OAuth vs. SAML
The platform has always supported OAuth-based social and enterprise login (GitHub, Google, Microsoft Entra, Okta). OAuth is well-suited for consumer and developer sign-in flows.
SAML is a different, older, and more widely adopted protocol in corporate IT environments. When a company's IT department says "all SaaS tools must use our SSO", they almost always mean SAML 2.0. Without it:
- IT administrators cannot enforce login through their IdP
- Access cannot be centrally revoked when an employee leaves
- The tool fails security reviews and procurement checklists
- Enterprise deals stall or collapse during due diligence
This release adds SAML 2.0 support, making the platform viable for enterprise procurement.
Supported Identity Providers
Any standards-compliant SAML 2.0 IdP is supported. Verified integrations include:
| Identity Provider | Protocol |
|---|---|
| Okta | SAML 2.0 |
| Microsoft Entra ID (Azure AD) | SAML 2.0 |
| OneLogin | SAML 2.0 |
| Any SAML 2.0-compliant IdP | SAML 2.0 |
OAuth logins (GitHub, Google, Microsoft Entra, Okta) remain available and unaffected.
How It Works
Authentication Flow
- A user visits the login page and selects Sign in with SSO
- They enter their work email address; the platform resolves the correct IdP based on the domain
- The user is redirected to their corporate IdP login page
- The IdP authenticates the user and posts a signed SAML assertion back to the platform
- The platform validates the assertion's signature using the stored x509 certificate
- A session is created and the user is logged in
What the Platform Stores
For each SAML-enabled tenant, the following IdP metadata is persisted:
- Entity ID — the unique identifier for the IdP
- SSO URL — the IdP's SAML endpoint that receives authentication requests
- x509 Certificate — used to verify the signature on SAML assertions
- Attribute Mappings — maps IdP-supplied attributes (e.g.
email,firstName) to platform user fields
Setting Up SAML (Enterprise Admins)
Prerequisites
- An active Enterprise plan subscription
- Admin access to your organisation's Identity Provider
- Your IdP's metadata XML file or the individual endpoint values (Entity ID, SSO URL, certificate)
Steps
- Log in as a workspace admin and navigate to Settings → Security → Single Sign-On
- Select Configure SAML
- Choose your IdP from the list or select Custom SAML 2.0 Provider
- Upload your IdP metadata XML, or enter the Entity ID, SSO URL, and x509 certificate manually
- Copy the platform's ACS (Assertion Consumer Service) URL and Entity ID into your IdP application configuration
- (Optional) Configure attribute mappings if your IdP uses non-standard attribute names
- Click Test Connection to validate the configuration before saving
- Click Save & Enable — SAML is now active for your workspace
Note: Once SAML is enabled, you can optionally enforce it for all members of the workspace, preventing OAuth logins. This setting is available under Settings → Security → Enforce SSO.
Attribute Mapping Defaults
The following attribute names are expected by default. Override these in the attribute mapping UI if your IdP uses different names.
| Platform Field | Default SAML Attribute |
|---|---|
email | |
| First Name | firstName |
| Last Name | lastName |
| Display Name | displayName (fallback: firstName + lastName) |
Plan Availability
| Feature | Starter | Pro | Enterprise |
|---|---|---|---|
| GitHub / Google OAuth | ✅ | ✅ | ✅ |
| Microsoft Entra / Okta OAuth | ✅ | ✅ | ✅ |
| SAML 2.0 SSO | ❌ | ❌ | ✅ |
| Enforce SSO for all members | ❌ | ❌ | ✅ |
Coming Next
- SCIM provisioning — automatic user provisioning and deprovisioning from the IdP (planned)
- Just-in-time (JIT) provisioning — automatically create accounts on first SAML login (already supported in this release via attribute mapping)
- Audit log for SSO events — login, logout, and configuration change events surfaced in the compliance dashboard
Troubleshooting
The "Test Connection" step fails. Verify that the ACS URL registered in your IdP exactly matches the value shown in Settings. Trailing slashes and HTTP vs. HTTPS mismatches are the most common cause.
Users see an "Invalid SAML assertion signature" error. Re-download and re-upload your IdP's x509 certificate. Certificates rotate on a schedule in some IdPs (Okta, for example, supports multiple active certificates during rotation windows).
Users are logged in but fields like name are blank.
Check the attribute mapping configuration. Your IdP may be sending givenName / sn (LDAP-style) rather than firstName / lastName.
SAML option does not appear on the login page. SSO / SAML is only available on the Enterprise plan. Confirm your subscription tier in Settings → Billing.