What is single sign-on (SSO)?
The feature that turns up in the first enterprise security questionnaire, usually right before the deal closes.
In short
Single sign-on (SSO) lets people sign in to many applications with one login, usually their company account at an identity provider such as Okta, Microsoft Entra ID or Google Workspace. Your app trusts that provider through SAML or OpenID Connect, so the customer's IT team controls who can access your product.
Also called: SSO, Enterprise SSO, SAML SSO
Why it matters when your prototype goes to production
Consumers do not ask for SSO; companies do. The moment you sell to a business with an IT department, its security review will ask whether staff can sign in with the company account, and whether access ends when someone leaves. Without SSO the answer is a spreadsheet of passwords.
What adding it involves
- An auth provider that supports SAML and OpenID Connect per customer organisation. Clerk and similar services do.
- Accounts grouped by organisation, so each customer's staff land in the right workspace.
- Roles that map to what the customer's IT team assigns.
- A plan for people who were signed in when their company access is removed.
It is much easier when the app was built multi-tenant from the start, with organisations and roles in the data model.
Common questions
What is the difference between SSO and SAML?
SSO is the experience of one login for many apps. SAML is one of the standards used to deliver it; OpenID Connect is the other.
Can SSO and MFA work together?
Yes. The identity provider usually enforces multi-factor authentication, so your app inherits it through SSO.
Related terms
Read next
Sources
More on this: Production architecture & security · All glossary terms
Built something in Lovable you want people to rely on?
We are the engineers who take it the rest of the way — secured, tested, released and supported.