Add SSO to Your B2B SaaS (and Escape the SSO Tax)

Adding SSO to your B2B SaaS means letting an enterprise's own identity provider (Okta, Entra, Google Workspace) authenticate users into your app instead of your password database. You support SAML or OIDC, map each customer's identity connection to their org, and provision users on first login. Done right, it unblocks six-figure deals that will not sign without it.

Why enterprise buyers demand SSO

Enterprise buyers demand SSO because it moves user lifecycle control from your app to their identity team, which is a security and compliance requirement, not a nice-to-have. When an employee is offboarded, IT disables one account in the identity provider and access to every connected SaaS tool dies with it. Without SSO, your app is an island: a separate password, a separate offboarding step, and an audit finding waiting to happen.

For the buyer, SSO is usually a hard gate. Their security review will ask whether you support SAML, and a "no" can end the deal before pricing. This is why SSO so reliably unblocks contracts: it is not a feature the champion wants, it is a control the security team requires. If your first enterprise prospect just asked for it, treat it as deal-critical infrastructure, not a backlog item. For the broader context on why identity is the enterprise attack surface, see Application Security 101.

SAML vs OIDC: which to support first

Support SAML first, because that is what enterprise identity teams have deployed and know how to configure. OIDC is the more modern, developer-friendly protocol built on OAuth 2.0 and JWT, but the enterprise install base still runs on SAML 2.0, an OASIS standard ratified in 2005. If you can only build one path this quarter, build SAML.

The two protocols solve the same problem with different plumbing. SAML exchanges XML assertions over browser redirects and POST bindings. OIDC exchanges JSON tokens over HTTPS and is far simpler to debug. A deeper protocol walkthrough lives in OAuth 2.0 vs OIDC vs SAML.

Practical rule: support SAML to win enterprise deals today, add OIDC when a customer's identity provider prefers it or when you need it for mobile. Do not treat one as a replacement for the other. See the OIDC core spec at openid.net/specs/openid-connect-core-1_0.html.

Reference architecture: how the flow actually works

The core flow is a browser round-trip: your app (the Service Provider, or SP) redirects the user to the customer's Identity Provider (IdP), the IdP authenticates them, and it posts a signed assertion back to your Assertion Consumer Service (ACS) URL. You validate the signature, read the user's identity, and start a session. That is SSO in one sentence.

Two initiation patterns exist. SP-initiated starts in your app: the user clicks "Log in with SSO," you generate an AuthnRequest, and you redirect to the IdP. IdP-initiated starts in the customer's dashboard (the Okta tile), where the IdP posts an unsolicited assertion straight to your ACS URL. Support SP-initiated first because it is the cleaner, more secure default. IdP-initiated is convenient for users but has known replay and phishing edges, so validate strictly if you accept it.

The pieces you must get right:

• Metadata exchange. Each side publishes an XML metadata document (entity ID, endpoints, signing certificate). You import theirs, they import yours. This is the setup handshake.
• ACS URL. The single endpoint on your side that receives the SAML response. Per-tenant or app-wide, but it must be exact; a trailing-slash mismatch breaks everything.
• Signing. The IdP signs assertions with its private key; you verify with its public certificate. Always require signed assertions. Reject unsigned ones.
• Encryption. Optional. Assertions already travel over TLS, so most deployments skip assertion encryption unless the customer mandates it.

Read the actual response format in the SAML 2.0 core spec (docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf) before you write a parser. Better yet, do not write a parser, which is the next section.

Build vs buy: roll your own or use an SSO API

Buy unless SSO is your core product. Rolling your own SAML means implementing XML signature validation, canonicalization, and a per-IdP quirk matrix, and XML signature verification is a documented source of authentication bypass vulnerabilities when done wrong. An SSO API (WorkOS, Auth0, Stytch, and peers) gives you one normalized interface across SAML and OIDC and every enterprise IdP, so you integrate once instead of per customer.

The honest tradeoff is money versus time and risk. A library like ruby-saml or passport-saml is free but puts the security-critical signature logic on you. An SSO API charges per connection but absorbs the IdP-specific bugs and the on-call load. For a founding engineer with one enterprise prospect, buy: you will ship in days, not weeks, and you will not be the person who shipped a signature-bypass bug.

For a like-for-like feature and pricing comparison of managed identity platforms, use the Top IAM solutions comparison rather than a list I would only duplicate here. Whichever managed vendor you pick, keep the connection config abstracted behind your own interface so you can migrate later.

Multi-tenant modeling: connections, orgs, and provisioning

Model SSO as a one-to-one link between an IdP connection and an org (tenant), never between a connection and a user. Each enterprise customer configures one SAML connection; that connection belongs to their organization record in your database; every user who authenticates through it is stamped with that org's ID. This is the single most important data decision, and getting it wrong means users landing in the wrong tenant.

On first login, use JIT (just-in-time) provisioning: when a validated assertion arrives for a user your database has never seen, create the account on the spot, attach it to the connection's org, and assign a default role (almost always the lowest-privilege member role, never admin). The IdP is the source of truth for identity, so trust the email in the assertion for that org's domain and skip your own email-verification step for SSO users.

Two rules that save you later:

• Match users by a stable NameID or email, decided up front. Emails change; a persistent NameID does not. Store both.
• Do not let SSO users set a local password. Their credential lives in the IdP. Mixing the two creates an account-takeover path.

For scaled deployments, layer SCIM on top of SSO so the IdP can push user creates, updates, and deactivations proactively instead of relying on JIT at login. SSO authenticates; SCIM provisions and deprovisions. Ship SSO first, add SCIM when a customer asks.

The SSO Tax, and where I land

The "SSO Tax" is the industry pattern of gating SSO behind the most expensive enterprise tier, often at a multiple of the next plan down, so a security baseline becomes a luxury upsell. The site sso.tax has documented this for years, and it is worth being honest about: SSO does cost you real engineering and support, so charging for it is fair. Charging 4x the mid-tier price to unlock a checkbox is not.

Here is where I land. SSO is a security control, and pricing a security control out of reach makes your customers less safe, which is a bad look and, increasingly, a competitive liability. Fair packaging looks like this: include SSO on any paid business plan at a modest premium, price it against your real cost to support connections (not against the buyer's desperation), and never make it the reason a mid-market customer stays on shared passwords. Charge for seats, provisioning automation, audit logs, and support SLAs. Do not charge a ransom for the front door lock. Your security team will thank you, and so will your renewal rate.

Testing with a real IdP and the failure modes

Test against a real identity provider, not just your own mocks, because the failure modes only show up with a genuine IdP. Every major provider offers a free developer tenant: Okta (developer.okta.com), Microsoft Entra ID (a free Azure tenant), and Google Workspace SAML apps. Set up a connection in each, because their quirks differ, and their combined market share is most of the enterprise install base you will actually see.

The failure modes you will hit, roughly in order of frequency:

• Clock skew. SAML assertions carry NotBefore and NotOnOrAfter timestamps. If your server clock drifts from the IdP's by more than the allowed window, valid logins fail with a "not yet valid" error. Run NTP and allow a small tolerance (60 seconds is typical).
• Certificate rotation. IdP signing certificates expire. When the customer rotates theirs and you are still pinning the old public cert, every login breaks at once. Track expiry dates and support updating the cert without downtime.
• NameID mismatch. You expect email as the NameID; the IdP sends a persistent opaque ID, or vice versa. Users get duplicate accounts or cannot log in. Agree on the NameID format during setup and validate it.
• ACS URL and entity ID typos. A single wrong character in the metadata means the IdP posts to the wrong place or refuses to. Copy-paste, never retype.

Require MFA at the IdP as part of your enterprise security story; it is the customer's job to enforce it, but you should document that you expect it.

What SSO actually costs you

SSO costs you ongoing maintenance, not just the initial build, and that is the number founders forget. The integration is a fraction of the lifetime cost. The recurring burden is certificate rotation (every cert expires and every rotation is a potential outage), IdP-specific support tickets (each customer's admin configures things slightly differently), and the on-call risk that a signature or clock bug locks an entire enterprise out at 9am on a Monday.

Budget for it honestly. Every SSO connection is a small standing support relationship: setup assistance, the occasional broken-login escalation, and a cert-expiry calendar entry. This recurring cost is exactly why buying a managed SSO API pays off for most teams, and exactly why charging something for SSO is defensible. The line to hold is the one from the SSO Tax section: price it to cover this real cost, not to extract a premium from a security requirement.