What is single sign-on (SSO)?

When do customers start asking for single sign-on?

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.

How does a single sign-on login work behind the scenes?

With SSO, your app never checks the password. It sends the user to their company's identity provider, the provider signs them in under its own rules, and it sends back a signed statement saying who they are. Your app checks that statement against the trust set up for that customer and opens a session.

In practice the user types a work email. The app sees the domain, for example acme.com, finds Acme's connection, and redirects to Acme's provider. Whether the provider asks for a password, a passkey or a second factor is Acme's decision. When Acme's IT team removes someone, that person can no longer start a new sign-in.

What does adding SSO to an existing app involve?

Adding SSO means four pieces of work: an auth provider, such as Clerk, that supports SAML and OpenID Connect per customer organization; accounts grouped by organization so staff land in the right workspace; roles that map to what the customer's IT team assigns; and a plan for people whose company access is removed.

• An auth provider that supports SAML and OpenID Connect per customer organization. Clerk and similar services do.
• Accounts grouped by organization, 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 organizations and roles in the data model.

Can a Supabase or Lovable app offer SAML single sign-on?

Yes. Supabase Auth supports SAML 2.0 single sign-on with any SAML 2.0 identity provider, including Okta, Microsoft Entra, Google Workspace and OneLogin. Its docs say it needs the Pro plan or above, is off by default, and is configured per customer with the Supabase CLI. Your app then starts sign-in with signInWithSSO and the customer's domain.

• Turn on SAML 2.0 on the Auth Providers page in the Supabase dashboard.
• Add each customer's connection with supabase sso add, using their metadata URL and email domains.
• Start the flow from your app. Supabase notes that flows started at the identity provider do not work with PKCE.
• Map each signed-in user to the right organization and role before showing any data.

The last step is where AI-built apps usually fall short: sign-in works, but every company's staff share one pool of data. If you are moving a prototype toward enterprise customers, our guide to taking a Lovable app to production covers the order of work, and pricing shows how we take it on.