SSO

Single sign-on: authenticating once against a central identity provider that vouches for the user across services.

Single sign-on means the password check happens somewhere else. Your user clicks Sign in with Google, Microsoft Entra or Okta, that provider verifies who they are, and hands your application a signed assertion you can trust. One login session then covers multiple tools, and in company settings the employer, not the employee, administers who gets in.

Why it matters to an indie builder: SSO is the most common line item on enterprise checklists, and its absence is a common reason self-serve products lose their first big customer. The moment a 50-seat prospect's security review asks for Okta integration, you need an answer. It is also the most consequential authentication upgrade you can offer a company: joiners get access in minutes and leavers lose it everywhere at once.

A concrete example: a team-collaboration tool sells to a 60-person company. The IT reviewer's first question is whether login goes through their Entra directory. A product that wired SAML or OIDC through WorkOS, Clerk or Auth0 answers yes, passes review, and lands a $1,200 monthly contract. A product without it is asked to become enterprise-ready and stall in procurement. The integration, bought rather than built, cost less than the first month of that contract.

Common mistakes: hand-rolling SAML (the protocol is notorious for edge cases, metadata formats and clock skew; use a vendor), confusing SSO with social login (Sign in with Google for consumers is convenience; SSO is the company controlling identity, and enterprises price the difference), leaving SCIM provisioning out of the plan (reviewers increasingly expect accounts to be created and deactivated from the directory), and charging for SSO per seat in a way that reads as a security tax, which the market has begun to punish. The sso-capable auth blocks on IndieBoot, from WorkOS to Clerk, are listed with exactly this checklist in mind.