Single Sign-On (SSO): SAML, OIDC, and Why Enterprises Won't

Single sign-on lets enterprise users authenticate to your app using their company's identity provider (Okta, Azure AD.

Single Sign-On: The Enterprise Checkbox That Unlocks a Different Sales Motion

Single sign-on (SSO) is authentication delegation: instead of your app maintaining passwords for enterprise users, users authenticate against their employer's identity provider (IdP) — Okta, Microsoft Entra (Azure AD), Google Workspace, OneLogin, Ping — and your app trusts the resulting assertion. SSO matters commercially because enterprise IT departments effectively require it for any application storing meaningful company data. Missing SSO is one of the most common reasons B2B SaaS deals over $20K ACV stall at security review.

SAML vs. OIDC

Two protocols dominate. SAML 2.0 is the older enterprise standard — XML-based, verbose, browser-mediated redirect flows. Every major enterprise IdP supports it; Okta and Azure AD default to it for enterprise apps. OIDC (OpenID Connect) is the modern JSON/OAuth 2.0-based alternative, better developer ergonomics, but not universally supported by every enterprise IdP in every enterprise's configuration. Practical answer: support both if you can, but SAML is the one that closes deals. OIDC-only shops exist but are the minority in enterprise sales.

The pricing question

Historically many SaaS products gated SSO behind expensive enterprise tiers ($$$-per-seat premiums), which the sso.tax movement critiqued as extractive since SSO is a security feature. Modern practice is more nuanced: SSO is often included in mid-tier plans, with just-in-time provisioning and SCIM (auto-provision/deprovision) gated to enterprise. Whatever the policy, be explicit in pricing pages — hiding the tier requirement until sales conversations damages trust with security teams evaluating you.

Build vs. buy

Building SSO in-house means implementing SAML (or OIDC), handling IdP-specific quirks (Azure AD, Okta, and Google Workspace all have edge cases), supporting SP-initiated and IdP-initiated flows, and maintaining it as protocols evolve. Estimated engineering cost: 2-4 engineer-months for a solid implementation, plus ongoing maintenance. Buying via WorkOS, Auth0, Frontegg, or Stytch shortens this to 1-2 engineer-weeks and offloads the IdP-compatibility work. For most startups, buy — the engineering time saved pays for the service many times over.

Configuration and onboarding

Each enterprise customer configures the SSO connection between their IdP and your app: exchange metadata URLs and certificates, map user attributes (email, name, groups), decide on JIT provisioning. This setup is fiddly enough that many SaaS products require an implementation call. Better: self-serve admin flows that walk customers through IdP-specific setup with screenshots for each major provider. WorkOS's admin portal is the reference; teams that build this themselves should study it before starting.

SCIM: the other half

SSO handles login. SCIM (System for Cross-domain Identity Management) handles user provisioning — auto-creating users when they're added to a group in Okta, auto-deactivating them when they leave the company. Without SCIM, enterprise admins manually create and remove users in your app, which they hate. SCIM is required for larger enterprise deals (typically 500+ seat customers). See the SSO & SCIM page for the full picture.

Frequently asked questions

When should we ship SSO?
When you're actively losing deals to its absence, or approaching $500K+ ARR with enterprise upmarket motion. Below that, the engineering effort likely doesn't pay for itself — but plan the architecture assuming SSO is coming so retrofit isn't painful.
Do we need to support every IdP?
Support the SAML 2.0 standard generically and you'll cover 95% of enterprise buyers. Explicit certifications for Okta and Azure AD help sales conversations; other IdPs work through generic SAML configuration.
Can users have SSO and password auth on the same account?
Enterprise customers usually want SSO to be exclusive — once configured for their domain, all users must authenticate via SSO. Individual users on personal accounts keep password auth. Domain-based routing handles this: user enters email, app routes to the appropriate auth method based on domain configuration.

Related fundraising guides (40)

Investor directory · Fundraising library · Articles A–Z · Company funding database