Protocols and how-tos
SAML SSO for B2B SaaS: what enterprise customers will ask for
How SAML 2.0 single sign-on works for a B2B product, SP- versus IdP-initiated flows, per-tenant configuration, and the assertion checks that matter.
The short answer
For a B2B SaaS product, SAML SSO means each enterprise customer's identity provider (Okta, Microsoft Entra ID, Google Workspace and others) authenticates their employees and sends your application a signed XML assertion. You need per-tenant IdP configuration, a reliable way to route a user to the right IdP, strict assertion validation, and a decision about what happens to local passwords once SSO is on.
Sources last reviewed .
The moving parts
Your application is the service provider (SP). Each customer registers your SP's entity ID and Assertion Consumer Service (ACS) URL in their IdP and gives you their IdP's metadata: entity ID, SSO URL and signing certificate. Because every customer has a different IdP, the configuration is per tenant, not global.
SP-initiated and IdP-initiated
SP-initiated: the user starts at your login page, you identify the tenant (usually from email domain or a tenant-specific URL), and redirect an AuthnRequest to their IdP. The response's InResponseTo ties it to your request. IdP-initiated: the user clicks your tile in their IdP portal and an unsolicited assertion arrives. It is popular with customers and weaker, because there is no request to correlate with; accept it only with strict replay protection, or redirect it into an SP-initiated flow.
Assertion validation
- Verify the XML signature with the tenant's configured certificate, and make sure the signature covers the assertion you then read — XML signature wrapping attacks exploit code that validates one element and reads another.
- Check Audience, Recipient/Destination, NotBefore and NotOnOrAfter, and InResponseTo for SP-initiated flows.
- Reject replayed assertion IDs within their validity window.
- Use a maintained SAML library; hand-written XML signature handling is a reliable source of vulnerabilities.
Decisions customers will ask about
- Enforce SSO for the tenant (disable local passwords) — usually required, with a break-glass administrator path.
- Just-in-time provisioning on first sign-in, and deprovisioning via SCIM, since SAML alone cannot tell you someone has left.
- Certificate rotation without downtime: accept two certificates during the overlap.
In Authreads
How this applies to Authreads
SAML and SCIM are Planned on the Authreads roadmap, not available today. Hosted login over OpenID Connect, per-tenant security policy and the management API are available.
Authreads is a multi-tenant identity platform in beta. Capability status is maintained on /roadmap as Available, In progress or Planned.
Keep reading
Protocols and how-tos
SCIM provisioning explained: automating user lifecycle for B2B
Multi-tenant architecture
Per-tenant SSO: routing each customer to their own identity provider
Multi-tenant architecture
B2B login flows: invitations, domains, SSO and the first admin
Glossary: SAML · Single sign-on (SSO) · SCIM
Building on any of this?
Tell us what you're putting together. We'll tell you plainly whether Authreads fits it.