The Deal That Stalled at "Do You Support SAML?"
I have watched this exact scenario play out with more than one client. A promising enterprise deal moves through the pipeline — the eval goes well, the champion is sold, procurement is engaged — and then it hits a wall that has nothing to do with the product itself. Someone from the buyer's IT security team fills out a vendor questionnaire, gets to the line item for "Single Sign-On (SAML 2.0 or OIDC)," and the honest answer is "not yet." The deal doesn't die immediately. It goes quiet. Weeks pass. Eventually someone tells you, politely, that they've gone with a competitor who checked that box.
This is not a hypothetical. Industry reporting consistently puts missing SSO among the most common deal-blocking gaps in enterprise SaaS procurement, and it increasingly shows up as a baseline requirement rather than a premium add-on — buyers expect it in the plan they're already paying for, not as a costly upsell. If you sell into mid-market or enterprise accounts and your platform still relies on username-and-password logins, you are leaving revenue on the table for reasons that have nothing to do with your product's features.
Why This Isn't a Feature Request — It's a Procurement Gate
The reason SSO shows up so early in enterprise deals is that it isn't really about convenience for the end user. It's about how the buyer's IT department manages risk across every vendor in their stack.
When a company standardizes its identity on a provider — Okta, Microsoft Entra ID, Google Workspace, Ping Identity — every application layered on top inherits that company's access policies automatically. When an employee leaves, IT deactivates one account and access to every connected app disappears with it. When the company mandates multi-factor authentication, it applies everywhere, without asking each vendor to implement it separately. When an auditor asks who had access to a system and when that access was revoked, the answer lives in one place instead of scattered across dozens of vendor admin panels.
A vendor that doesn't support SSO breaks that model. It means the buyer's security team has to trust that your app enforces its own password policy, its own MFA, and its own offboarding process correctly, every time, forever. For a company that answers to SOC 2 auditors or cyber insurance underwriters, that's a risk they would rather not carry — and no SSO is an easy reason to disqualify a vendor before anyone even discusses price.
Getting the Vocabulary Straight
I recommend technical and non-technical stakeholders align on a few terms before scoping the work, because sales conversations and engineering conversations often use them loosely:
- SSO (Single Sign-On) is the outcome — a user logs in once with their company identity and gets access without a separate password for your app.
- SAML 2.0 is the older, XML-based protocol most enterprise identity providers still default to. It's what most security questionnaires mean when they ask whether you support SSO.
- OIDC (OpenID Connect) is the modern, JSON/REST-based protocol built on top of OAuth2. It's simpler to implement and increasingly preferred by newer identity providers, though not every enterprise buyer has migrated to it yet.
- SCIM is a separate, related protocol for automated user provisioning and deprovisioning — it's what lets an IT admin add or remove a user in Okta and have that change propagate into your app automatically.
In my experience, buyers ask for "SSO" but actually evaluate three things: authentication (SAML/OIDC), provisioning (SCIM), and audit logging. Scoping a project around SAML alone, without accounting for SCIM and logging, is the most common reason SSO projects run longer than planned.
Build vs. Buy: The Decision That Actually Matters
This is where I steer almost every client toward the same answer, and it tends to surprise people who assume "we're a dev shop, we should build it ourselves."
Building SAML and OIDC support from scratch means owning certificate rotation, clock-skew handling, IdP-specific quirks (Okta, Entra ID, and Ping Identity each interpret parts of the SAML spec slightly differently), and a testing matrix across every identity provider your customers might run. I have seen internal teams budget a few weeks for this and land closer to a full quarter once they hit their first customer with a non-standard IdP configuration.
The alternative is an identity middleware layer — WorkOS, Auth0's Organizations feature, or similar overlay platforms — that sits between your application and your customers' identity providers. You integrate once against the middleware's API, and it handles the protocol translation for every IdP on the other side. For most B2B platforms below significant scale, this is the right call:
- Build custom SAML/OIDC only if you have highly unusual identity requirements, dozens of enterprise customers already signed and waiting, or genuine legal or compliance reasons that require owning the identity code directly.
- Use an overlay platform if you have a handful of enterprise prospects asking for SSO now and need to close deals in weeks, not quarters. This is the right default for most companies reading this.
- Budget realistically either way. Even with an overlay platform, plan for real engineering time on your side — session and user-matching logic, an admin UI for connecting identity providers, and testing against at least two real customer IdP configurations, not just a sandbox.
This decision connects to a broader pattern I discuss in custom API integration work: the platforms that make integration painless are worth paying for, because the alternative cost isn't just engineering hours — it's the deals that stall while you build.
The Implementation Pitfalls That Turn a Week Into a Quarter
Even with a good middleware choice, I see the same mistakes repeatedly:
- Treating SSO as single-tenant. If your platform serves multiple organizations, which is the norm for B2B SaaS, each customer connects its own identity provider independently. A design that assumes one identity provider for the whole app has to be reworked before it can support a second enterprise customer — it's the same multi-tenancy discipline that matters when scaling a B2B web portal for enterprise volume.
- No fallback for account matching. New employees show up in the identity provider before anyone tells your app about them. You need a clear rule, usually just-in-time provisioning by email domain, for what happens the first time someone logs in via SSO without an existing account.
- Ignoring SCIM until a customer demands it. Manual user management is fine for five users. Enterprise IT expects automated deprovisioning the moment someone leaves the company, and that's a SCIM integration, not an SSO one.
- Under-testing against real identity providers. A SAML integration that works against your own test Okta tenant can still break against a customer's Entra ID configuration with custom claim mappings. Test against at least two different providers before calling it done.
- No admin self-service. Enterprise IT wants to configure its own SSO connection without opening a support ticket. Building even a basic self-service setup flow keeps your team from becoming the bottleneck for every new enterprise customer.
Where I'd Start
If you're fielding your first "does your platform support SSO" question from a prospect, don't panic and don't over-scope it. Start by identifying which two or three identity providers your active prospects actually use, evaluate an overlay platform against those, and get a working SAML/OIDC connection live with your first real enterprise customer before building anything more elaborate. The goal isn't a perfect identity architecture — it's removing the one line item that's currently costing you deals.