What Is Single Sign-On? And When Your SaaS Needs It

What SSO means in a business context

Single sign-on lets people access your product using credentials their employer already controls, rather than a username and password held only by you. The company runs an identity provider; your application trusts it. When someone signs in, they are redirected to their employer's login, authenticate there, and return with a signed assertion that says who they are. Your application never sees the password.

The reason enterprises insist on this is not convenience. It is that access becomes one thing they control centrally: they can require multi-factor authentication, enforce their own session rules, and — the part that matters most — revoke someone's access to every tool at once when they leave. Without SSO, an employee who leaves keeps working accounts in every product that was ever signed up for individually.

How it differs from things it gets confused with

Social login — signing in with a personal Google, Microsoft or GitHub account — looks similar to a user and is different to a buyer. The identity belongs to the individual rather than the company, so it does not give an administrator any control and does not end when employment does. It is a good conversion feature and not a substitute for enterprise SSO.

Provisioning is also a separate thing. SSO answers who is signing in; provisioning creates, updates and deactivates accounts in your product to match the company's directory, usually via SCIM. Buyers often ask for both under one name. It is worth being explicit about which you support, because a company that has SSO but no provisioning still has to remove leavers from your product by hand.

The protocols, briefly

Two standards cover almost everything you will meet. SAML is older, XML-based, and still the default in large enterprises. OpenID Connect sits on top of OAuth 2.0, is JSON-based, and is more pleasant to implement. Support for one is enough to start; which one depends on your customers, and asking two or three of them is faster than guessing. Most teams use an identity library or a service rather than implementing assertion validation themselves, which is a reasonable decision given that a signature-verification mistake here is an authentication bypass.

When it is time to build it

The clearest signal is a deal. SSO appears in security questionnaires and procurement checklists, and above a certain company size it is a requirement rather than a preference — the buyer cannot sign without it regardless of how much they like the product. If you are hearing it in sales calls, it has already become a revenue question.

The second signal is internal: multiple customers asking how to remove access for people who have left, or asking whether you can enforce their password policy. Both are the same underlying need. Below those signals, building SSO early is usually premature — it is a meaningful piece of work with a long tail of per-customer configuration support.

What it costs you after launch

Implementation is the smaller half. Each enterprise customer needs their connection configured and tested, and identity provider setups vary in ways documentation does not always predict, so plan for support time rather than a one-off build. You also need to decide how SSO interacts with your existing login: whether a company can require it for their domain, what happens to accounts created before it was enabled, and how administrators and support staff get in if the identity provider is down. That last question should be answered before the first outage, not during it.

Finally, be careful about pricing it. Charging a large premium for SSO is common and increasingly criticised, on the grounds that a control that protects everyone should not be reserved for the largest plan. A defensible middle path is to include basic SSO broadly and reserve directory sync, audit log export and advanced administration for higher tiers.