Enterprise Single Sign-On Implementation: SAML, OIDC, Provisioning and Common Mistakes
How to add enterprise SSO to a SaaS product: SAML vs OIDC, per-tenant identity providers, SCIM and just-in-time provisioning, role mapping and testing.
How do you implement enterprise SSO in a SaaS product?
Support both SAML 2.0 and OpenID Connect through a proven authentication provider or library; let each tenant configure its own identity provider; route users to the right provider by verified domain or tenant URL; provision users with SCIM (or just-in-time with reviews); map identity provider groups to your roles; keep a break-glass administrator; and test against the identity providers your customers use. SSO is a sales requirement for many enterprise buyers and a security control for them.
This guide is for SaaS product and engineering teams. For the protocols, see OAuth 2.0 vs OpenID Connect; for permissions, SaaS roles and permissions.
Key takeaways
- Offer SAML and OIDC; use a proven provider or library.
- One identity provider configuration per tenant (sometimes several).
- Verify domains before using them for routing.
- SCIM for joiners, movers and leavers.
- Map groups to roles; keep least privilege.
- Test with real identity providers before customers do.
Architecture
| Component | What it does |
|---|---|
| Tenant SSO configuration | IdP metadata, certificates, protocol, attribute mapping, enforcement settings |
| Discovery | Route users to their IdP by verified domain or tenant URL |
| Protocol handling | SAML assertions or OIDC tokens validated by a proven library |
| Provisioning | SCIM endpoints (RFC 7644) or just-in-time creation |
| Role mapping | IdP groups or claims mapped to product roles |
| Sessions | Session lifetime, re-authentication for sensitive actions, logout |
| Admin tools | Self-service setup, test connection, audit logs, break-glass account |
Validation and security
- Validate SAML signatures, audience, recipient, timestamps and replay (SAML 2.0 Core).
- Validate OIDC ID tokens: signature, issuer, audience, expiry and nonce.
- Match users on a stable identifier from the IdP, not just email.
- Do not let a tenant claim a domain without proving ownership.
- Support certificate rotation without downtime.
- Log sign-ins, failures and configuration changes.
Admin experience
Customer administrators should be able to set up SSO themselves with clear instructions for common identity providers, test the connection before enforcing it, choose whether SSO is optional or required, map groups to roles, and see recent sign-in activity. Keep at least one break-glass account with strong MFA so customers are not locked out if their identity provider fails.
Hypothetical example: a B2B analytics SaaS
This example is hypothetical. An analytics SaaS lost deals because it lacked SSO. It added SAML and OIDC through an authentication provider, built a tenant settings page with metadata upload, a test button and group-to-role mapping, verified email domains through DNS records, and added SCIM so customers' leavers were deactivated automatically. It tested with the identity providers its prospects used before announcing the feature.
Common mistakes
- Matching accounts on unverified email addresses.
- Accepting unsigned or poorly validated assertions.
- Just-in-time provisioning with no deprovisioning.
- Enforcing SSO with no break-glass access.
- Only testing with one identity provider.
Related guides
- Multi-tenant SaaS architecture for tenant configuration.
- Passkeys for phishing-resistant sign-in for non-SSO users.
- Secrets management for certificates and client secrets.
- API security best practices for token handling.
Conclusion
Enterprise SSO is a combination of standard protocols and careful product work: per-tenant configuration, verified routing, provisioning, role mapping, admin tools and testing. Use proven libraries for the protocols and invest in the experience around them. For automating access when people join, move and leave, see joiner-mover-leaver automation.
Adding SSO to win enterprise customers?
ZSpace Labs is an India-based, remote-first technology studio working with Australian and international businesses on secure SaaS applications, authentication and integrations. If it would help to plan SSO and provisioning, we are happy to talk it through.
Common questions.
Ideally both. Many enterprises still use SAML 2.0 for workforce single sign-on, while OIDC is common for newer integrations. Most identity platforms and authentication providers support both, so offering both removes a sales blocker.