Software Growth

SSO (Single sign-on)

SSO lets a customer's employees log in to your product with their company identity provider, using SAML or OIDC, instead of a separate password.

Single sign-on means a user signs in once with their company account (through Okta, Microsoft Entra, Google Workspace and similar) and is let into your app without creating a separate password. For a B2B SaaS, it is the feature that most often shows up in a security questionnaire and the one that most often decides whether a larger customer can buy.

Why customers ask for it

EnterpriseReady puts it bluntly: managing hundreds or thousands of users across tens or hundreds of applications is nearly impossible without central identity. SSO gives the IT team one place to turn access on and off, enforce MFA and meet audit requirements. When an employee leaves, disabling their company account closes your app too. Pair it with SCIM to automate creating and removing users.

SAML vs OIDC

  • SAML is the older, XML-based protocol. Almost every enterprise identity provider supports it, and many procurement teams ask for it by name. It is harder to implement.
  • OIDC (OpenID Connect) is built on OAuth 2.0 and JSON. It is simpler and fits modern web and mobile apps.

WorkOS recommends supporting both: OIDC first for speed, SAML when enterprise customers require it. Let each customer pick, per organization.

The SSO tax debate

Many vendors lock SSO behind the top plan. The site sso.tax (the SSO Wall of Shame) argues that security should not be a premium feature and lists over 150 vendors with large markups, such as Mixpanel going from $20 to $833 a month. Vendors reply that SSO has real costs: engineering, support for each identity provider, and a customer base that tends to be large, demanding and willing to pay.

A fair middle view: SSO is both a security control and a way to segment. Charging for it makes sense if the plan above it is clearly built for larger teams. Charging 20 to 40 times the base price for the same feature is what draws criticism. Consider whether your tier structure makes the jump look reasonable.

What it costs to build

  • An admin page where customers paste metadata or issuer details.
  • Login routing, usually by email domain.
  • Just-in-time user creation, and a fallback admin login so a bad config does not lock people out (EnterpriseReady recommends this).
  • Testing against more than one identity provider.

Building SAML yourself can take weeks and keeps costing support time. Many small teams buy it from a vendor such as WorkOS instead, paying per connection.

When a small SaaS should care

When deals above roughly 20 seats stall on it, or when two prospects in a quarter ask. Before that, Google and Microsoft social login cover most small teams. Once you add it, put it in a higher tier or a clearly priced add-on and publish the price, since hidden pricing is exactly what the critics object to.

Related terms

Sources

Back to the SaaS glossary