Adding SSO (SAML and OIDC) to a B2B SaaS: Build or Buy

For most B2B SaaS teams, buy SSO rather than build it: a managed provider such as WorkOS or Auth0 handles SAML and OIDC for each customer's identity provider, and your app links each login to a tenant. WorkOS charges $125 per connection a month for the first 15 (WorkOS pricing). Build your own only if SSO is core to your product and you can test SAML properly.

If you would rather have SSO built into your product for you, see how RAITHub would build this below.

What is SaaS SSO, and why do enterprise customers ask for it?

Single sign-on (SSO) lets a customer's employees sign in to your app with their company account, through an identity provider (IdP) such as Okta, Microsoft Entra ID or Google Workspace. Your app is the service provider (SP). The customer's IT team gets one place to grant and revoke access, enforce MFA and see sign-ins. When someone leaves, IT disables one account and access to every app goes with it.

That is why SSO appears in almost every enterprise security questionnaire, and why many SaaS products put it on their top plan. If you are preparing for those buyers, making a SaaS MVP enterprise-ready covers the other items they ask for.

Should I support SAML or OIDC?

Both, eventually, but SAML first if you sell to large companies. The two protocols do the same job in different formats:

	SAML 2.0	OpenID Connect (OIDC)
Format	Signed XML assertions posted through the browser	JSON Web Tokens over OAuth 2.0
Typical customer	Large enterprises, older IdP setups, government and education	Newer companies, Google Workspace, developer-heavy teams
Setup exchange	Metadata XML: entity ID, ACS URL, signing certificate	Issuer URL, client ID and secret
Main implementation risk	XML signature validation; parser quirks	Token and redirect validation
Spec	OASIS SAML 2.0	OpenID Connect Core 1.0

In SAML, the browser carries every message: the SP never talks to the IdP directly, and the SP validates each response with the IdP's public certificate (Okta's SAML concepts guide). A managed provider hides that difference: you integrate once, and it speaks SAML or OIDC to each customer.

What do WorkOS, Auth0 and Okta charge for SSO?

Provider	What you pay for	Price (checked 7 October 2026)
WorkOS SSO	Per customer connection	$125 a month each for 1–15 connections, $100 for 16–30, $80 for 31–50, $65 for 51–100; Directory Sync priced the same way; AuthKit user management free up to 1 million monthly active users (WorkOS pricing)
Auth0 B2B	Plan by monthly active users, with enterprise connections included	B2B Essentials includes 3 enterprise SSO connections and starts at $150 a month for 500 MAUs; B2B Professional includes 5; extra connections $100 a month each, up to 30. B2C plans do not include enterprise connections (Auth0 pricing)
Okta Workforce Identity	Your customer's side: the IdP their employees use	From $6 per user a month for Starter, which includes SSO, with a $1,500 annual minimum (Okta pricing)

Okta appears here because it is usually what your customer already runs, not what you buy. Your job is to be a well-behaved service provider for it. Do the arithmetic for your own plan: if SSO sits on a plan that earns several hundred dollars a month per customer, a per-connection fee is easy to absorb; if it sits on a cheap plan, it is not. Enforcing plans and add-ons in code covers how to gate it.

How does SSO fit a multi-tenant SaaS?

Each customer organisation gets one or more SSO connections. A user's sign-in must end up inside the right tenant, and only that tenant. The design decisions that matter:

• Routing. Decide which connection to use from the email domain the user types, or from a tenant-specific login URL. Only route by domain after the customer has proved they own it.
• Identity linking. Link an SSO identity to a user by the stable pair of connection and IdP user ID, not by email alone. Emails change, and an IdP you do not control can assert any email address.
• Tenant check. After every sign-in, confirm the profile's organisation is the tenant the user is entering.
• Just-in-time provisioning. Create the user on first sign-in, with a default role. Map IdP groups to roles only through an explicit, tenant-scoped mapping; see SaaS authorisation and RBAC design.
• Enforcement. Let tenant admins require SSO, which turns off password sign-in for their users, but keep a break-glass admin route. Okta's guide recommends a separate sign-in URL that does not trigger the SAML redirect, so a broken configuration cannot lock everyone out (Okta).
• Audit. Log every SSO sign-in, failure and configuration change; audit log design covers the schema.

What does the callback code look like with a managed provider?

With WorkOS, you send the user to an authorisation URL for their organisation, then exchange the returned code for a profile and check it (WorkOS SSO docs). A minimal Next.js route handler:

import { WorkOS } from '@workos-inc/node'
import { findTenantByWorkosOrg, upsertSsoUser, startSession } from '@/lib/auth'

const workos = new WorkOS(process.env.WORKOS_API_KEY)

export async function GET(req: Request) {
  const url = new URL(req.url)
  const code = url.searchParams.get('code')
  const expectedTenantId = url.searchParams.get('state') // set when the flow started
  if (!code || !expectedTenantId) return new Response('Bad request', { status: 400 })

  const { profile } = await workos.sso.getProfileAndToken({
    code,
    clientId: process.env.WORKOS_CLIENT_ID!,
  })

  const tenant = await findTenantByWorkosOrg(profile.organizationId)
  if (!tenant || tenant.id !== expectedTenantId) {
    return new Response('Forbidden', { status: 403 })
  }

  // Link by connection + IdP user ID, never by email alone.
  const user = await upsertSsoUser({
    tenantId: tenant.id,
    connectionId: profile.connectionId,
    idpId: profile.idpId,
    email: profile.email,
  })
  return startSession(user)
}

In production, sign or encrypt the state value, or keep it server-side, so it cannot be swapped. Auth0 models the same idea as Organizations, each with its own connections, members and roles (Auth0 Organizations docs).

What does building SAML yourself involve?

More than parsing XML. The OWASP SAML Security Cheat Sheet lists what a service provider must validate on every response: the signature, using the IdP's certificate you stored rather than one embedded in the message; a signature algorithm of at least RSA-SHA256; that the signed element is the assertion you actually read; Destination and Recipient against your ACS URL; Audience against your entity ID; InResponseTo against a request you sent; NotBefore and NotOnOrAfter; replay detection; and RelayState only as an allowlisted redirect.

Mistakes here are account takeovers. In March 2025, GitHub's security lab disclosed that ruby-saml used two XML parsers that read the same document differently, which let an attacker holding one valid signature sign in as any user (GitHub Security Lab). The same month, the Node.js library xml-crypto fixed a critical signature-verification bypass, CVE-2025-29775 (OSV advisory). Both were in widely used libraries maintained by people who know SAML well. If you build, use a maintained library, pin it, watch its advisories and test the validation rules yourself.

A self-hosted open-source IdP broker such as Keycloak is a middle path: no per-connection fee, but you run, patch and monitor it.

What about SCIM and user provisioning?

SSO decides who can sign in. SCIM, the System for Cross-domain Identity Management (RFC 7644), lets the customer's IdP create, update and deactivate users in your app automatically. Without it, a user removed from the IdP can no longer sign in, but their account, sessions and API tokens in your app may live on. Large customers ask for SCIM soon after SSO. WorkOS sells it as Directory Sync, priced per connection like SSO (WorkOS pricing). Whatever you choose, revoke sessions and tokens when a user is deactivated.

How do I test SSO before a customer does?

• Cross-tenant sign-in. Start a flow for tenant A and complete it with a user from tenant B's IdP. It must fail.
• Email collision. Configure a test IdP that asserts an email belonging to an existing password user in another tenant. No link should be made.
• Tampered responses. If you validate SAML yourself, test an unsigned assertion, an expired one, a wrong audience and a replayed response. All must be rejected.
• Deprovisioning. Deactivate a user in the IdP and confirm sessions and tokens die.
• Lockout. Break a tenant's SSO configuration and confirm the break-glass route still works.

A developer or trial tenant from each IdP your customers use gives you a realistic test matrix. The OWASP Top 10 testing checklist puts these under A07, Authentication Failures, and RAITHub's security testing covers them at application level.

How long does adding SSO take?

With a managed provider, a developer who knows your auth code can usually ship a first SAML and OIDC connection in 3–5 days, plus admin screens for connection setup, domain verification and SSO enforcement. A self-built SAML implementation with proper validation, tests and admin tooling is several weeks. The main risk of doing it yourself is not the happy path, which works quickly, but the validation rules and the identity-linking logic that decide whether one customer's IdP can reach another customer's data.

Buy, build or hire?

Route	Example	Choose this when
Off-the-shelf SSO provider	WorkOS, Auth0 B2B (prices above)	You sell to enterprises, have a handful to a few dozen SSO customers, and want SAML handled by people who do nothing else. The right default for most B2B SaaS.
Template or open-source broker	Keycloak, or the SSO features of an auth library; see Better Auth vs NextAuth vs Clerk	Per-connection fees would hurt your margins and you have the people to run and patch an identity service.
Custom build on a SAML library	Your own service provider code with a maintained library	SSO is part of what you sell, or you have hundreds of connections, and you will invest in validation tests and advisory monitoring.

Why RAITHub for this

• Tenant isolation is RAITHub's core skill. Sundor Skin, a B2B wholesale platform RAITHub built, has 88 permission codes across 12 staff roles, PostgreSQL row-level security and a CI suite that tries to read other buyers' data. SSO identity linking plugs into that kind of model.
• Tested, not assumed. Cross-tenant and deprovisioning cases are written as automated tests.
• Honest proof. RAITHub has not published an SSO case study; the guidance here is engineering practice, not a claimed track record.

When you don't need RAITHub

• Your auth provider already supports enterprise connections and your team has done an SSO integration before. Follow its docs.
• Your buyers require a certified vendor. RAITHub is not SOC 2 or ISO 27001 certified.
• You want developers placed under your management. RAITHub does not offer staff augmentation.

How RAITHub would build this

• Scope: SAML and OIDC SSO through a managed provider, or a self-hosted broker if fees rule it out; tenant routing and domain verification; identity linking by connection and IdP user ID.
• Admin: self-serve connection setup, SSO enforcement per tenant, group-to-role mapping and a break-glass route.
• Provisioning: just-in-time users, then SCIM or Directory Sync with session and token revocation.
• Tests and audit: cross-tenant, email-collision, deprovisioning and lockout tests in CI, and every SSO event in the audit log.

Timeline: SSO usually ships as part of a fixed-scope SaaS engagement of 4–6 weeks for enterprise readiness, or within backend work of 6–12 weeks if it comes with a wider API or identity rebuild. You receive: automated tests and CI, handover docs and runbooks for connection setup, and full IP under NDA. See SaaS development. Next step: book the free 15-minute technical audit, then get a written fixed quote.

Last reviewed: 7 October 2026. Provider prices checked on 7 October 2026.

Frequently asked questions

What is the difference between SAML and OIDC for SSO?

Both let a user sign in through their company's identity provider. SAML uses signed XML assertions and is common in large enterprises. OIDC uses JSON Web Tokens over OAuth 2.0 and is common with newer setups. A managed provider lets you support both through one integration.

How much does it cost to add SSO to a SaaS?

With WorkOS, $125 per customer connection a month for the first 15, falling with volume. Auth0's B2B plans include 3 or 5 enterprise connections, with extra connections at $100 a month. Building it yourself avoids those fees but costs engineering time and ongoing maintenance.

Should I build SAML SSO myself?

Only if SSO is core to your product or you have very many connections. SAML validation is easy to get subtly wrong, and mistakes become account takeovers, as the 2025 ruby-saml and xml-crypto vulnerabilities showed.

Do I need SCIM as well as SSO?

Larger customers usually ask for it. SSO controls sign-in; SCIM lets the customer's identity provider create and deactivate accounts in your app automatically, so leavers lose access, sessions and tokens without manual work.

Should SSO be on every plan?

That is a pricing decision. Many SaaS products put SSO on their business or enterprise plan because per-connection costs and support effort are real. If security-minded small teams are your market, offering it lower can win deals.

How do I stop SSO users landing in the wrong tenant?

Verify domain ownership before routing by email domain, link identities by connection and IdP user ID rather than email, check the profile's organisation against the tenant on every sign-in, and test cross-tenant sign-in in CI.