I’m building a B2B product and need SAML login for customers

Absolutely — for a B2B product, SAML SSO is a common enterprise requirement.

Here’s the practical view of what you need to build:

What SAML login gives you

• Customers can sign in using their company identity provider (IdP), like Okta, Azure AD / Entra, OneLogin, Ping, Google Workspace, etc.
• Your app becomes the Service Provider (SP).
• Their IdP authenticates the user and sends you a signed SAML assertion.

Typical architecture

1. User clicks “Sign in with SSO”
2. Your app redirects them to the customer’s IdP
3. IdP authenticates the user
4. IdP POSTs a SAML assertion back to your ACS endpoint
5. You validate the assertion and create a session in your app

Core things you need to implement

1) Tenant-level SSO configuration

For each customer org, store:

• IdP entity ID
• IdP SSO URL
• X.509 certificate(s) for signature verification
• Whether SSO is enforced or optional
• Allowed email domains
• SP metadata values

2) SAML endpoints

Usually:

• ACS endpoint: receives SAML Response
• Metadata endpoint: exposes your SP metadata
• Optional: Single Logout endpoints if you support SLO

3) Assertion validation

You must verify:

• Signature is valid
• Assertion is intended for your SP
• Audience matches your app
• NotBefore / NotOnOrAfter timing is valid
• Recipient / ACS URL is correct
• Assertion hasn’t been replayed
• The user identity is mapped to the right tenant

4) User provisioning / mapping

Decide whether you support:

• Just-in-time provisioning: create users on first login
• SCIM provisioning: customer pre-provisions users/groups
• Or both

5) Account linking rules

You need a policy for:

• Matching SAML users to existing accounts
• Handling email changes
• Preventing users from logging into the wrong tenant
• Enforcing domain restrictions

Recommended product approach

For B2B SaaS, the usual pattern is:

• Username/password for smaller customers
• SAML SSO for enterprise customers
• Optional OIDC later if customers request it
• SCIM for lifecycle management if you want enterprise readiness

Build vs buy

Build it yourself if:

• You have strong auth/security engineering resources
• You need full control
• You’re okay supporting many IdP quirks

Use a provider if:

• You want to ship fast
• You want less risk
• You don’t want to maintain SAML edge cases

Common options:

• Auth0
• WorkOS
• Clerk
• OneLogin
• Okta Customer Identity
• FusionAuth
• AWS Cognito (less pleasant for enterprise SSO flows)

For B2B SaaS, WorkOS is especially popular because it abstracts a lot of SAML + SCIM complexity.

Important security notes

• Never trust unsigned assertions
• Require strict audience and destination checks
• Use certificate rotation support
• Prevent replay attacks
• Log SSO events for auditability
• Bind users to tenants carefully
• Consider requiring email domain + IdP config match

If you’re implementing yourself

The most common stack libraries are:

• Node.js: passport-saml, samlify
• Python: python3-saml
• Ruby: ruby-saml
• Java: Spring Security SAML / OpenSAML
• .NET: Sustainsys.Saml2
• Go: less mature; many teams use a hosted provider

A good minimal feature set

If you want an MVP:

• Org-level SAML config
• ACS endpoint
• Metadata generation
• SP-initiated login
• User creation on first login
• Basic signature/audience validation
• Tenant routing by email domain or org slug

Next question to answer

The implementation differs depending on:

1. What backend stack you’re using
2. Whether you want to build SAML yourself or use a provider
3. Whether you need SCIM too

If you want, I can give you:

• a step-by-step implementation plan
• a database schema for SAML tenant config
• or code examples for your stack (Node, Python, Ruby, Java, .NET).