When to Add SSO to Your SaaS, and Why It's Not the Enterprise Paywall Anymore

Single sign-on used to be an enterprise gate. Now it's table stakes for anyone selling to companies larger than 20 people. When to add SSO to your SaaS has shifted from "eventually" to "sooner than you think" — and the pricing debate around it has shifted too.

This post is the version of the SSO conversation we have with founders during scoping calls. When it's time, what to build, what tools help, and how to price it without making the internet mad at you.

What SSO actually is

Single sign-on lets users log into your app using their existing corporate identity — Google Workspace, Microsoft 365, Okta, or another identity provider. Instead of a new password, the user's employer vouches for them.

Under the hood, two protocols do the work. SAML is the older, more common one in enterprise. OpenID Connect is newer, cleaner, and used by Google and Microsoft workspaces. Most SSO implementations support both.

The signals that mean it's time

SSO isn't for every SaaS. But when it's time, the signals are unmistakable.

Enterprise deals ask for it in the security questionnaire

The most concrete signal. If two consecutive deals ask about SSO — even asked casually — you're one deal away from losing one over its absence.

Your target buyer is a company with 20+ employees

Below that, buyers usually don't care. Above it, admins increasingly enforce SSO for every SaaS tool the company uses.

You're mid-scoping with a customer above $30k ACV

SSO conversations start when the deal size gets serious. If you're pricing above $30k a year, expect it. Above $100k, it's non-negotiable.

Users at the same company are creating separate accounts

A soft signal but a useful one. Users at the same domain signing up individually means the buyer isn't in control of the account, which means procurement is going to catch it eventually.

What to build first

Don't try to support every identity provider at once. Two implementations cover the majority of enterprise deals.

SAML SSO with SCIM

SAML for authentication, SCIM for user provisioning. This combo works with Okta, Azure AD, Google Workspace (in SAML mode), OneLogin, and most enterprise IdPs. Ship this one and 80% of enterprise buyers are covered.

Google Workspace SSO via OIDC

For small and mid-sized companies. Cheaper for the buyer, simpler for you. Add after SAML unless your buyer base skews heavily to Google-only shops.

Just-in-time provisioning

The lightweight alternative to full SCIM. When a user logs in via SSO for the first time, their account is created automatically. Simpler, gets you most of the value, and works for most buyers.

Build vs buy

SSO implementation is one of those problems that looks simple and takes months when built from scratch. Buying is almost always the right call.

WorkOS

Built specifically to add SSO to a SaaS quickly. Handles SAML, SCIM, and OIDC through one API. Fast to integrate. Pricing scales with SSO customer count, which aligns with revenue.

Auth0 or Clerk

Full auth platforms with SSO as one feature. Better fit if you haven't already built authentication. Overkill if you have auth and just need SSO.

Firebase or Supabase auth

Support SAML in limited ways. Fine for basic SSO to a single IdP. Buyers with more complex IdP setups will hit friction.

Build from scratch

Possible, but budget 2-3 engineer-months minimum. Every IdP has quirks — Okta's XML nesting, Azure's attribute mapping, Google's OIDC scopes. The maintenance cost adds up. For most teams, buy.

The pricing question

The most contentious part of SSO in 2027.

For years, the standard was locking SSO behind the highest-tier "Enterprise" plan. This became known as the "SSO tax" — charging small companies enterprise prices for a security feature.

The pushback has been strong enough that many SaaS have moved SSO down the plan hierarchy. Some make it available on all paid plans. Some charge a small add-on per SSO-enabled organization.

What we usually recommend

Two approaches, both defensible.

Option one: SSO available on all paid plans at no extra cost. Simplest, best PR, and removes a friction point in every enterprise deal.

Option two: SSO available on the mid-tier plan or higher — Business or Growth, not Enterprise-only. A small tier gate that doesn't feel like extortion.

The one we don't recommend anymore: SSO gated behind a $50k+/year Enterprise plan for a $30/user product. Buyers push back publicly, and the reputational cost isn't worth the ARR gain.

The implementation timeline

Rough numbers if you use a service like WorkOS.

• Basic SAML SSO with just-in-time provisioning: 1-2 weeks.
• SCIM user provisioning: 2-3 weeks on top.
• Multiple IdP support and custom attribute mapping: another 1-2 weeks.
• Admin UI for buyers to self-configure their SSO: 2-4 weeks.

That last one is often skipped and later regretted. Every enterprise buyer wants to configure their own SSO. If they have to email support to set up metadata, you've added friction to every deal.

Mistakes we see

Building SSO before there's a buyer asking. Enterprise features without enterprise buyers is expensive theater. Wait for two concrete asks before scoping.

Supporting five IdPs on day one. Every IdP has quirks. Ship one — usually Okta or Google Workspace — get it stable, then add. Don't try to boil the ocean.

Skipping SCIM. SSO without user provisioning means IT admins can't deactivate accounts automatically. They will notice, and it will cost you a deal.

Making it a support ticket to enable. Every buyer should be able to configure their SSO themselves through your admin UI. If it requires an email, it's incomplete.

Charging small companies enterprise prices for SSO alone. The SSO tax pattern is well-known and buyers push back. Price it fairly across tiers.

Trade-offs

SSO adds attack surface. Every additional integration is a potential vulnerability. Every misconfigured buyer setup is a customer support ticket. The cost isn't just build; it's operate.

SSO also raises expectations. Buyers who see SSO expect audit logs, role-based permissions, and other enterprise features to follow. Shipping SSO without a plan for the next few enterprise readiness features can trap you between "past SSO" and "not yet enterprise-ready."

Our post on SaaS security audits covers the broader enterprise readiness picture.

Common misconceptions

"SSO is a technical feature." It's a commercial feature. Buyers care because it satisfies procurement. Engineering treats it as a project; the value is in the sales cycle.

"We can wait until we have an Enterprise plan." By the time you have an Enterprise plan, you've probably lost a deal or two over its absence. Add SSO when the buyer signals show up, regardless of plan naming.

"OAuth counts as SSO." Signing in with Google is convenient. It's not SSO in the enterprise sense — no centralized admin control, no automatic deprovisioning. Buyers know the difference.

Frequently asked questions

Final take

SSO in 2027 is closer to a hygiene feature than an enterprise gate. Add it when the signals arrive — usually earlier than founders expect — and price it in a way that doesn't make the internet angry. WorkOS or a similar service lets a small team ship real SSO in a few weeks. The build is manageable; the discipline of not putting it off is harder.

If you're scoping SSO for your SaaS and want a review of the buy-versus-build decision or the plan structure, book a call. We'll walk through the trade-offs and tell you what we'd ship first.