Implementing Enterprise SSO: SAML 2.0 and OIDC for B2B SaaS

SAML 2.0 or OIDC

SAML 2.0 remains the default in large enterprises because of its long history in enterprise identity and its support in every major identity provider. It is verbose, XML-based and idiosyncratic across vendors, but it is expected and its absence is often a procurement blocker.

OpenID Connect is simpler, JSON-based and better suited to modern applications and mobile clients. Many enterprises now support both, so the pragmatic answer for a SaaS platform is to implement both and let each tenant choose.

Whichever you support, use a well-maintained library rather than implementing signature validation or token parsing yourself. XML signature wrapping and token validation errors are a well-known source of vulnerabilities.

• Support both SAML 2.0 and OIDC and let the tenant choose.
• Never implement signature or token validation from scratch.
• Assume each identity provider deviates from the specification.
• Store all protocol configuration per tenant, not globally.

Modelling identity per tenant

Identity configuration is tenant data. Each tenant has an issuer, metadata or discovery URL, signing certificates that rotate, an attribute mapping, and one or more verified email domains that determine which users belong to it.

Domain verification is what allows a user to type an email address and be routed to the correct identity provider. Enforce ownership of each domain, because a domain claimed by two tenants creates an account takeover path.

Certificate rotation is the operational event that breaks SSO most often. Support overlapping certificates, alert before expiry and provide clear diagnostics so a customer administrator can see exactly why authentication failed.

Provisioning with SCIM

Authentication alone is not enough. When an employee leaves, their access must be revoked everywhere, and doing that manually across every SaaS product is a security and administrative burden that enterprises will not accept.

SCIM provides a standard interface for creating, updating and deactivating users and groups. Deprovisioning is the critical path: it must immediately revoke sessions and API tokens, not merely mark an account inactive.

Where SCIM is not available, support just-in-time provisioning on first login, mapping identity provider attributes to roles. This reduces onboarding friction but does not solve deprovisioning, so also enforce short session lifetimes and support bulk deactivation.

• Implement SCIM for automated user and group lifecycle management.
• Revoke sessions and tokens immediately on deprovisioning.
• Support just-in-time provisioning as a fallback.
• Map identity provider groups to platform roles explicitly.

Operating SSO at scale

Support cost grows with tenant count, so self-service configuration is not optional. Provide guided setup per identity provider, a validation step that actually tests the configuration, and error messages that name the failing assertion attribute rather than reporting an authentication failure.

Log every authentication attempt with the tenant, the identity provider, the subject and the failure reason, and give customer administrators access to their own tenant's logs. This eliminates a large share of support tickets because the customer can diagnose their own configuration problem.

Finally, keep an escape hatch. Enterprise identity providers have outages. A documented, audited break-glass path for tenant administrators, with strong controls and alerting, is far safer than an improvised one during an incident.

• Provide guided, self-service identity provider configuration.
• Expose tenant-scoped authentication logs to customer admins.
• Validate configuration with a real test at setup time.
• Maintain an audited break-glass access path.