Every B2B SaaS meets identity the same way: a deal is going well, the champion loves the product, and then someone from the customer’s IT team sends a security questionnaire. Question three is “Do you support SSO?” — and if your answer is “we have Sign in with Google,” the deal stalls. Not because your auth is bad, but because you answered a different question than the one enterprise procurement asks.
Part 1 established whose data is whose. This part is about whose identity is whose — and the quiet 2026 reality behind it: per a 2026 Gartner survey, 78% of enterprise IT leaders treat SSO integration and compliance certifications as mandatory for adopting a new SaaS tool, and organizations with proper identity management report 42% fewer security incidents. Identity is not a feature. It is the door to enterprise revenue.
Three things called “login”
The confusion starts with vocabulary. Three different systems get called “login,” and only one of them is what the questionnaire means:
- Social login (“Sign in with Google”) — authentication against a consumer account. Convenient, and completely different from enterprise SSO: the user owns the identity, and the customer’s IT department controls nothing. No questionnaire accepts it.
- Your own auth — email/password or passkeys issued by you, sessions managed by you. You (the vendor) hold the keys. Necessary, but it makes your customer’s IT depend on your policies instead of theirs.
- Enterprise SSO + SCIM — the customer’s employees authenticate against the customer’s identity provider (Okta, Microsoft Entra ID, Google Workspace, Ping, OneLogin, JumpCloud), and accounts are provisioned and deprovisioned from the customer’s directory. The customer’s IT holds the keys. This is what “do you support SSO” means.
The protocols: SAML 2.0 and OIDC, in procurement reality
The flow itself is simple, and it is the same in both protocols: your app never sees a password. The user is redirected to their company’s IdP, authenticates there — under the IdP’s own MFA and conditional-access policies — and returns with a signed assertion (SAML) or JWT (OIDC) that your app verifies against the IdP’s published keys.
The two protocols differ in everything else:
| SAML 2.0 | OIDC | |
|---|---|---|
| Era / format | 2002, XML assertions | 2014, JSON/JWT on OAuth 2.0 |
| Configuration | Manual metadata + certificate exchange | Auto-discovery URL + JWKS key rotation |
| Sweet spot | Browser-based enterprise SSO | SPAs, mobile, APIs, dev-facing flows |
| Awkwardness | XML parsing, cert rotation on both sides, mobile | Token storage and redirect-URI discipline |
And here is the part that surprises developers: procurement questionnaires still say “SAML 2.0 SSO” by name, even though OIDC is technically the more modern protocol. The reason is installed base — Entra ID, Okta, ADFS, and Ping deployments configured years ago speak SAML, and the people writing the questionnaires write what they run. The 2026 answer is not to choose: support both. SAML because it wins enterprise deals, OIDC because newer IdPs and your own developer flows prefer it.
The implementation hazards to respect either way: SAML demands care with assertion replay and metadata tampering (validate signatures, honor NotOnOrAfter, pin the IdP’s certificate); OIDC demands strict redirect-URI matching, short-lived access tokens, and nonce validation. Both are secure when implemented properly. “Properly” is why almost nobody implements them by hand anymore — more on that below.
SCIM: the half everyone forgets
SSO gets users in. It says nothing about getting them out. That second half is SCIM (System for Cross-domain Identity Management), and for IT buyers it is not optional — it is the actual point.
The lifecycle is three events, all flowing from the customer’s directory: a joiner gets an account provisioned with the right role; a mover changing teams gets roles updated; a leaver gets deprovisioned — access dies automatically, at 6 p.m. on a Friday, with no support ticket to your team. Without SCIM, offboarding is an email thread and a prayer, and orphaned accounts accumulate — exactly the accounts that show up in breach postmortems. This is why “SSO + SCIM” travels as a pair in every questionnaire, and why vendors like Clerk shipping SCIM to GA (April 2026) made industry news.
Build vs buy: the 2026 landscape
Supporting SAML and OIDC and SCIM across six IdPs, with per-tenant configuration and a self-service admin portal, is months of protocol grunt work you will not enjoy maintaining. The market has stratified so you don’t have to:
- WorkOS — the enterprise-readiness layer: SSO, SCIM, directory sync, and audit logs as APIs, priced flat per connection. Pairs with whatever session layer you already have (Better Auth, Clerk, your own). The canonical “close the enterprise gap in days” answer.
- Better Auth — the self-hosted answer: organizations, 2FA, passkeys, and SSO plugins in your own Postgres, no per-user pricing curve. You own the operations; your customers’ data stays in your database (see Part 1).
- Clerk — the hosted shortcut, repositioning toward B2B: polished components, organizations, and now SCIM. Fastest ship; pricing curves with MAU.
- PropelAuth — B2B-only, with a self-hosted sidecar (“BYO”) that bolts enterprise SSO onto an existing auth stack without a platform migration; unlimited connections, no per-connection fee.
- Auth0 — the mature incumbent: broadest protocol coverage, per-MAU pricing that scales aggressively past the free tier.
Watch the pricing shape more than the feature list: per-connection pricing (WorkOS, PropelAuth) rewards a few large enterprise tenants; per-MAU pricing (Auth0, Clerk) tracks consumer-style growth and can turn a successful enterprise quarter into a surprising invoice. And whatever you buy, check the same list your buyers will: both protocols, IdP coverage, SCIM, audit logs, and a self-service admin portal — the difference between a one-day onboarding and a two-week email thread.
The controls that go with it
SSO does not replace your baseline; it joins it. Three numbers to configure before the questionnaire arrives:
- MFA, enforced at the policy level — Microsoft’s defense data puts MFA at blocking >99% of identity-based attacks when enforced. The qualifier is the whole story: most breaches happen because MFA was optional. Make it server-side mandatory for high-value tenants, not a user preference.
- Passwordless as the default — for greenfield apps in 2026, “passkeys primary, password as fallback” is the shipping default; full password removal is a multi-year migration nobody finishes.
- Per-tenant session policy — access tokens at 15–60 minutes with refresh rotation, sessions idling out at 30–60 minutes with an 8–24 hour absolute cap — and configurable per tenant, because financial and healthcare customers will ask for halves of whatever you chose.
The questionnaire playbook
The documents are all the same. They ask: SSO (SAML 2.0?), SCIM, MFA enforcement, audit logs, SOC 2 report, DPA, data residency, encryption at rest and in transit, incident response process, and subprocessors. The winning answer pattern is “yes, with evidence”: a link to your trust page, the SOC 2 report (a later door in this series), the audit-log export, the DPA template. Every “no” is a deal review; every “yes, but—” is a two-week delay.
Where the series goes next
Current thinking for the next door: audit logs — the line item that separates “we take security seriously” from “prove it”: what to log, how to make it tamper-evident, and why your enterprise customer’s SOC team will ask for the export before their own lawyers ask for anything else. Billing security (webhook verification, the PCI boundary) is the other strong candidate. As before: the order is decided when we get there.
Practice
- Write out your current login surface: which of the three “logins” do you actually offer? If an enterprise questionnaire arrived tomorrow, which questions could you answer “yes, with evidence” — and which are honest “not yet”s?
- Sketch the SSO flow for your app on paper: where does the redirect go, what validates the assertion, where do the IdP’s keys come from, and what happens when they rotate?
- Trace one leaver scenario in your head: an employee of your biggest customer quits. Today, by what exact mechanism does their access to your product die, and how long does it take? If the answer involves a human remembering, that’s the gap SCIM fills.