Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.lovable.dev/llms.txt

Use this file to discover all available pages before exploring further.

This page documents SAML SSO for end users of your Lovable Cloud app. It is configured per project under Cloud → Users → Auth settings.Looking for SSO for your team’s access to Lovable itself? See Set up workspace single sign-on (SSO). That is a workspace-level setting and a different feature.

​
Overview

Lovable Cloud supports SAML 2.0 single sign-on (SSO) for your app’s end users. When enabled, users whose email domain matches your configuration are redirected to your identity provider (IdP), authenticate there, and return to your app already signed in. It appears alongside your other sign-in methods under Cloud → Users → Auth settings. Setting up SAML is a two-way exchange between Lovable and your identity provider:
  • Lovable → IdP: Copy two service-provider values (ACS URL and Audience URI) from Lovable into your IdP’s SAML application.
  • IdP → Lovable: Copy your IdP’s metadata URL back into Lovable, along with the email domains that should use this IdP.
Service provider (SP)-initiated sign-in only. Users must start sign-in from your app. IdP-initiated SSO (starting from a tile in the IdP’s dashboard) is not supported.

​
Why use SAML SSO

  • Centralized access management: Provision and de-provision in your identity provider, your app inherits those decisions
  • Inherit your organization’s MFA, conditional access, and device policies
  • Frequently required by enterprise customers during security and compliance reviews
  • Simpler sign-in for employees using their existing work accounts
If you only need consumer logins (email, Google, Apple), you do not need SAML SSO.

​
Common use cases

  • B2B SaaS products selling to enterprise customers
  • Internal tools where employees should sign in with their corporate identity
  • Apps shipped to a single customer who requires their identity provider for access

​
Prerequisites

  • A Lovable Cloud project (auth must be Lovable-managed)
  • SSO must be allowed by your workspace auth policy
  • Admin access to a SAML 2.0 identity provider (Okta, Microsoft Entra ID, Google Workspace, OneLogin, JumpCloud) that publishes a public metadata URL
  • The list of email domains to route to that identity provider, for example acme.com, acme.co.uk

​
Set up SAML SSO

Complete the following steps in order.
1

In Lovable: Open the setup form and copy the SP values

You can do this in chat or in the Cloud tab.
In your project chat, ask:
Enable SAML SSO for this app
Lovable opens an interactive Configure SAML SSO form. The top of the form shows your project’s ACS URL and Audience URI (SP Entity ID). Leave the form open, you will fill in the metadata URL and domains in Step 3.
Copy both URLs. They look like:
  • ACS URL: https://<project-ref>.supabase.co/auth/v1/sso/saml/acs
  • Audience URI: https://<project-ref>.supabase.co/auth/v1/sso/saml/metadata
If you already have your IdP’s metadata URL when you start, include it in your prompt and Lovable will pre-fill the form so you only have to confirm:
Set up SAML SSO using https://acme.okta.com/app/xyz/sso/saml/metadata for the domain acme.com
2

In your IdP: Create the SAML app and copy the metadata URL

In your identity provider, create a new SAML 2.0 application. Exact steps and field names vary by provider, use this mapping:
Lovable valueCommon IdP field namesWhat to enter
ACS URL (from Step 1)Single Sign-On URL, SSO URL, Reply URL, Assertion Consumer Service URLPaste the ACS URL
Audience URI (from Step 1)SP Entity ID, Audience URI, IdentifierPaste the Audience URI
Name ID formatName ID format, Name identifier formatEmailAddress
Email attributeAttribute Statements, Claims, User AttributesMap the user’s primary email to an email attribute
Then:
  • Assign the users or groups who should be able to sign in.
  • Copy your IdP’s metadata URL, you will need it in Step 3.
For provider-specific instructions, refer to your identity provider’s official documentation.
3

Back in Lovable: Paste the metadata URL and email domains

Return to the form you opened in Step 1.
  • SAML metadata URL: Paste the metadata URL you copied from your identity provider.
  • Email domains: Comma-separated list of domains to route to this identity provider, for example acme.com, acme.co.uk.
Click Submit (chat) or Save (UI). Users at those domains can now sign in through your SAML provider.
4

Add a sign-in entry point in your app

Enabling SAML configures authentication, but it does not automatically update your app’s UI. Your sign-in screen still needs an entry point that starts the SSO flow.Ask Lovable to add it:
Add a "Sign in with SSO" option to my sign-in page that prompts for an email and routes users to their SAML provider
Lovable will update the relevant components in your app. When that is done, you are ready to test the flow.

​
Test the sign-in flow

  1. Open your published app in an incognito window.
  2. Go to the sign-in page.
  3. Enter an email address at one of your configured domains (for example, you@acme.com).
  4. You should be redirected to your identity provider, authenticate there, and return to your app signed in.
If a user enters an email at a domain that is not in your SAML configuration, they will be offered the other sign-in methods you have enabled (for example, email, Google).

​
Manage your SAML configuration

  • Disable SSO. Toggle Enable SAML 2.0 single sign-on off. Existing users keep their accounts but can no longer sign in via SAML. They will need another enabled method.
  • Certificate rotation. If your identity provider rotates its signing certificate, the metadata URL usually stays the same and Lovable re-fetches it. If the URL itself changes, update it here.
  • Edit the configuration. Re-run the project chat flow or change the fields in the Cloud tab. Updates replace the existing connection.

​
Limitations

  • One SAML provider per project. You cannot connect two identity providers to the same project.
  • SP-initiated only. No IdP-initiated tile launches.
  • Metadata URL only. No XML upload or manual SP configuration.
  • No attribute-mapping UI. The user’s email comes from the SAML assertion as-is. Make sure your identity provider sends a stable email value.
  • No SCIM provisioning. Users are created on first successful sign-in (just-in-time). Removing a user in your identity provider prevents future sign-ins, but stale rows may remain in your project’s user table.
  • Domains route, they do not enforce. Configuring acme.com does not disable email or Google sign-in for acme.com users, it only routes them to your identity provider when they sign in using SSO. To enforce SSO-only, disable the other sign-in methods.

​
Troubleshooting

The metadata URL must return SAML metadata XML and be reachable from the public internet.
The user’s email domain is not in your Domains list, or they used a method (Google or email) that bypasses domain routing.
Almost always one of two things:
  • Your app isn’t reading the session after the redirect. Make sure you have an onAuthStateChange listener and that the SSO callback route is handled.
  • Your app’s URL isn’t in the redirect allow-list. If unsure, ask Lovable to: 
    Wire up the SSO redirect handling on my sign-in page
The SAML assertion is missing an email, or the ACS URL / Audience URI in your IdP does not exactly match the values shown in Lovable’s Advanced section. Re-check both.
Clock skew between your IdP and Lovable, or signing certificate mismatch. Re-fetch the metadata URL or update your IdP’s clock.
Map email to user.mail. If user.mail is empty, use user.userprincipalname.

​
FAQ

Workspace-level SSO controls how your team signs in to Lovable (the product). The SAML SSO described on this page controls how end users sign in to your Lovable Cloud app. See Set up single sign-on (SSO) for the workspace-level feature.
Any SAML 2.0-compliant IdP that publishes a metadata URL: Okta, Microsoft Entra ID, Google Workspace, OneLogin, JumpCloud, Auth0 (SAML mode), and others.
For Cloud app end-user SSO, only SAML 2.0 is supported today. OIDC is available for workspace-level SSO.
No. One SAML provider per Cloud project.
No. SP-initiated only. Users must start sign-in from your app.
Yes. Users are created the first time they successfully sign in via SAML.
No. There is no SCIM provisioning surface for Cloud project SAML. Manage user lifecycle in your IdP. When you remove a user there, future sign-ins are blocked.
Yes. Re-run the chat flow or change the fields in the UI. Updates replace the existing connection.
No. Other methods stay enabled unless you turn them off explicitly. To enforce SSO-only sign-in, disable email, Google, and any other methods you do not want.