Adding SAML SSO to a B2B SaaS App: Design and Steps

Your app is the service provider (SP) and the customer's system is the identity provider (IdP). In the common SP-initiated flow, a user enters their email, you find the organization's connection, and redirect them to the IdP with an authentication request. The IdP authenticates them and posts a signed assertion back to your assertion consumer service (ACS) URL. You verify the signature, check the audience and timing, and start a session.

Each side needs to share configuration: you give the customer your entity ID and ACS URL, and they give you their sign-in URL, entity ID and signing certificate, usually as a metadata file. Make these easy to copy in a settings page, since customers' IT teams will do this without you on the call.

Plan for many customers with different setups:

• An SSO connection record per organization with the IdP's metadata, certificate and status.
• Verified email domains per organization, proven by a DNS record, so nobody can claim someone else's domain.
• Attribute mapping for email, first and last name, and optionally groups or roles.
• A setting to require SSO for the organization, which disables password and social login for its members.
• A test-connection button and a log of recent SSO attempts with readable errors, which will save many support hours.

Tenant modeling matters here: the organization, not the user, owns the connection.

A sequence that works for most teams:

1. Add organizations, memberships and verified domains to your data model if they don't exist.
2. Choose a SAML library or provider rather than writing signature validation yourself.
3. Build the SP endpoints: metadata, login initiation and ACS.
4. Validate every assertion: signature, issuer, audience, recipient, expiry and replay protection.
5. Map attributes to a user and membership, creating them on first login (just-in-time provisioning) if allowed.
6. Test with a free test identity provider and then with a real customer in a pilot.
7. Document setup for the most common identity providers your customers use.

Never trust an unsigned or unverified assertion, and reject assertions meant for a different audience. These checks are the security of the whole feature.

Login is half the job. When an employee leaves the customer, their access should end quickly. Just-in-time creation handles arrivals but not departures; SCIM, a provisioning standard, lets the customer's directory create and disable users in your app automatically. Enterprises often ask for it after SSO, so design for it early even if you ship it later.

Account linking is the classic vulnerability. If someone already has a password account with an email in a verified SSO domain, decide how to merge without letting an attacker take over accounts. Only link when the domain is verified for the organization, and require the organization to own it. Session length and single logout are further customer requests to plan for.

SAML has many edge cases, such as certificate rotation, clock skew, encrypted assertions and identity providers that deviate from the standard. Providers such as Auth0 and Clerk sell B2B connections so you configure per-organization SSO instead of implementing the protocol. Check in a demo how each represents organizations, whether customers can self-serve setup, and what SSO costs per connection, since pricing structures differ.

If SSO is the only enterprise feature you need, building may be reasonable with a good library. If you also need SCIM, audit logs and many customers, buying usually costs less than the maintenance. Side-by-side detail is in Auth0 vs Clerk vs Stytch, Clerk vs Auth0 for B2B SaaS and Auth0 vs Clerk for software publishers.