Set up workspace single sign-on (SSO)

This page documents workspace-level SSO for your team’s access to Lovable itself. It is configured at the workspace level under Identity (Settings → Access → Identity).Looking for SAML SSO for the end users of your app? See Add SAML single sign-on to your app. Want apps you build to recognize signed-in workspace members without a login page? See Reuse Lovable workspace identity in your app. Both are different features.

Single sign-on (SSO) is available on Business and Enterprise plans and enables secure, centralized authentication across your organization. With SSO, users can access Lovable with one set of credentials, simplifying access management and improving security.

Service provider (SP)-initiated sign-in is supported for all providers: users start sign-in from Lovable.Identity provider (IdP)-initiated SSO (starting from an IdP dashboard tile) can optionally be enabled for SAML providers. See Set up IdP-initiated sign-in (SAML). OIDC providers support SP-initiated sign-in only.

Supported SSO protocols

Lovable supports both OIDC and SAML 2.0 protocols, enabling integration with all major identity providers (IdP) including Okta, Auth0, Microsoft Entra ID (Azure AD), and more.

OpenID Connect (OIDC): recommended; a modern identity layer built on top of OAuth 2.0 that provides identity verification.
SAML (Security Assertion Markup Language) 2.0: XML-based protocol for exchanging authentication and authorization data, widely used in enterprise environments.

Prerequisites

To connect your identity provider to Lovable using OIDC or SAML, you need:

IdP admin access (Okta, Auth0, Microsoft Entra ID, or any other provider you’re using)
Lovable workspace owner or admin role
A verified domain in Lovable, to prove domain ownership
To verify your domain, add the TXT record displayed in the UI to your DNS provider. See Verify a domain for your workspace for the full walkthrough, including record details and troubleshooting.

Start SSO setup in Lovable

SSO configuration is a two-way setup between Lovable and your identity provider:

Lovable → IdP: copy Lovable URLs and settings into your IdP app.
IdP → Lovable: copy your IdP’s issuer, metadata, and certificates back into Lovable.

The workspace owner or admin can set up SSO. To start, go to Identity (Settings → Access → Identity → Add SSO provider), then choose OIDC or SAML.

IdP configuration reference

When you start the SSO provider setup in Lovable, you see:

What to configure in your IdP (for example, app type, scopes, and attribute mappings)
Lovable URLs and identifiers you may need to enter in the IdP.

Use the reference below while configuring OIDC or SAML in your IdP.

OIDC
SAML

Application type: Web Application
Grant type: Authorization Code
Token method: POST (if configurable)
Redirect URI to copy and add to your IdP: https://auth.lovable.dev/__/auth/handler
OAuth scopes:
- Required: openid, email
- Recommended: profile

ACS URL (Assertion Consumer Service): https://auth.lovable.dev/__/auth/handler
SP Entity ID / Audience URI: https://auth.lovable.dev/__/auth/handler
IdP-initiated ACS URL (optional, see Set up IdP-initiated sign-in (SAML)): https://api.lovable.dev/sso/saml/idp-consume
Attribute mappings:
- email (required): ensure the format is set to EmailAddress
- displayName (recommended): map to user’s full name
- photoURL (recommended): map to user’s profile picture URL

Provider-specific setup guides

If you use Okta, Auth0, or Microsoft Entra, you can find provider-specific documentation for setting up SSO. If you use another provider, see Configure other providers. Before you begin, complete Start SSO setup in Lovable to get the settings and values you need to use in your IdP. For more information, refer to your IdP’s official documentation.

Configure Okta as your SSO provider

OIDC
SAML

Add the Lovable app in Okta

In the Okta Admin Console, go to Applications → Browse App Catalog.
Search for Lovable, then click Add Integration.
On the General Settings screen, set the Application label (for example, Lovable OIDC), then click Next.
On the Sign-On Options screen, select OpenID Connect.
Set Application username format to Email.
Click Done.

Provide Lovable with your IdP information

In Okta, copy the following values from the Sign On tab and enter them in Lovable.

Okta Issuer URL → Lovable OIDC Issuer URL/Discovery Endpoint
To find your issuer, click the OpenID Provider Metadata link on the Sign On tab. The issuer is your Okta domain, for example https://your-org.okta.com.
Okta Client ID → Lovable OAuth Client ID/Application ID
Okta Client Secret → Lovable OAuth Client Secret

Configure display name and SSO login identifier (tenant ID)

In Lovable, update these values as desired. The values are prepopulated based on your verified domain.

Display name: The name shown to users during authentication.
SSO login identifier (tenant ID): The URL users will use to sign in directly with SSO.

(Optional) Test configuration in Lovable

In Lovable, click Test configuration. If you configured everything accurately, the validation should be successful.

Finish OIDC provider configuration in Lovable

In Lovable, click Configure provider to finish the configuration of Okta as your OIDC SSO provider.

Add the Lovable app in Okta

In the Okta Admin Console, go to Applications → Browse App Catalog.
Search for Lovable, then click Add Integration.
On the General Settings screen, set the Application label (for example, Lovable SAML), then click Next.
On the Sign-On Options screen, select SAML 2.0.
Set Application username format to Email.
Click Done.

The SAML settings (ACS URL and Audience URI) are pre-configured by the Lovable integration. You do not need to enter any SAML values manually in Okta.Because these settings cannot be changed, the catalog app does not support IdP-initiated sign-in yet. For now, users signing in through Okta must start sign-in from Lovable.

Provide Lovable with your IdP information

In Lovable, choose between quick SAML provider setup or manual configuration:Option 1: Quick setup - import from metadata URL

In Okta, open the Sign On tab of the Lovable application, scroll to Metadata details, and copy the Metadata URL.
In Lovable, paste the metadata URL in Quick setup: Import from Metadata URL field.
Click Test & Import to automatically populate the required fields below.

Option 2: Manual configurationOpen the metadata URL in a new tab. Copy the following values and enter them in Lovable.

Okta SingleSignOnService Location → Lovable SAML SSO Sign-on URL from your IdP
Okta EntityID → Lovable Identity Provider Entity ID / Issuer
Okta X509Certificate → Lovable X.509 Signing Certificate (public key)
Paste the certificate value between the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines.

Configure display name and SSO login identifier (tenant ID)

In Lovable, update these values as desired. The values are prepopulated based on your verified domain.

Display name: The name shown to users during authentication.
SSO login identifier (tenant ID): The URL users will use to sign in directly with SSO.

Finish SAML provider configuration in Lovable

In Lovable, click Configure SAML Provider → Confirm & Enable SSO to finish the configuration of Okta as your SAML SSO provider.

Configure Auth0 as your SSO provider

OIDC
SAML

Create an application in Auth0

Go to Auth0 Admin Dashboard → Applications.
Click Create application. Select the Regular Web Applications application type.
Give the app a name, for example Lovable OIDC SSO.
Click Create.

Configure Allowed Callback URLs

In Auth0, go to your application settings.
Add the Allowed Callback URLs: https://auth.lovable.dev/__/auth/handler
Click Save.

Provide Lovable with your IdP information

In Auth0, copy the following values from the Settings tab and enter them in Lovable.

Auth0 Domain → Lovable OIDC Issuer URL/Discovery Endpoint (include https://)
Auth0 Client ID → Lovable OAuth Client ID/Application ID
Auth0 Client Secret → Lovable OAuth Client Secret

Configure display name and SSO login identifier (tenant ID)

In Lovable, update these values as desired. The values are prepopulated based on your verified domain.

Display name: The name shown to users during authentication.
SSO login identifier (tenant ID): The URL users will use to sign in directly with SSO.

(Optional) Test configuration in Lovable

In Lovable, click Test configuration. If you configured everything accurately, the validation should be successful.

Finish OIDC provider configuration in Lovable

In Lovable, click Configure provider to finish the configuration of Auth0 as your OIDC SSO provider.

Create an application in Auth0

Go to Auth0 Admin Dashboard → Applications.
Click Create application. Select the Regular Web Applications application type.
Give the app a name, for example Lovable SAML SSO.
Click Create.

Configure Allowed Callback URLs

In Auth0, go to your application settings.
Add the Allowed Callback URLs: https://auth.lovable.dev/__/auth/handler
Click Save.

Configure SAML2 Web App Add-on

In Auth0, navigate to Addons, and enable SAML2 Web app.
In Addon: SAML2 Web app → Settings, set:
- Application Callback URL: https://auth.lovable.dev/__/auth/handler
- Settings: paste the following mappings JSON

    {
      "mappings": {
        "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"
      },
      "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
    }

Click Enable.

Provide Lovable with your IdP information

In Lovable, choose between quick SAML provider setup or manual configuration:Option 1: Quick setup - import from metadata URL

In Auth0 → Addon: SAML2 Web app → Usage, locate the Identity Provider Metadata, and click the arrow icon to get the URL.
In Lovable, paste the metadata URL in Quick setup: Import from Metadata URL field.
Click Test & Import to automatically populate the required fields below.

Option 2: Manual configurationIn Auth0 → Addon: SAML2 Web app → Usage, copy the following SAML Protocol Configuration Parameter values and enter them in Lovable.

Auth0 Identity Provider Login URL → Lovable SAML SSO Sign-on URL from your IdP
Auth0 Issuer → Lovable Identity Provider Entity ID / Issuer
Auth0 Identity Provider Certificate (X509Certificate) → Lovable X.509 Signing Certificate (public key)
Download Auth0 certificate and copy the X509Certificate value. Paste the certificate value between the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines.

Configure display name and SSO login identifier (tenant ID)

In Lovable, update these values as desired. The values are prepopulated based on your verified domain.

Display name: The name shown to users during authentication.
SSO login identifier (tenant ID): The URL users will use to sign in directly with SSO.

Finish SAML provider configuration in Lovable

In Lovable, click Configure SAML Provider → Confirm & Enable SSO to finish the configuration of Auth0 as your SAML SSO provider.

Configure Microsoft Entra ID as your SSO provider

OIDC
SAML

Create an app registration in Microsoft Entra ID

Go to Microsoft Entra admin center → App registrations → New registration.
Give the app a name, for example Lovable OIDC SSO.
Configure Redirect URI:
- Select Platform as Web.
- Paste the redirect URL https://auth.lovable.dev/__/auth/handler and click Save.
Click Register.

Configure the optional claims

In Microsoft Entra, go to Token configuration → Add optional claim.
Select ID token and add the email claim.
Click Add.

Configure the API permissions

In Microsoft Entra, go to API permissions → Add a permission → Microsoft Graph.
Select Delegated permissions and add:
- email
- openid
- profile
Click Add permissions.

Provide Lovable with your IdP information

In Lovable, enter the following:

OIDC Issuer URL/Discovery Endpoint: format the URL as https://login.microsoftonline.com/{TENANT_ID}/v2.0
Replace the {TENANT_ID} with the Directory (tenant) ID from the Overview page in Microsoft Entra.

In Microsoft Entra, copy the client ID value from the Overview page and enter it in Lovable.

Microsoft Entra Application (Client) ID → Lovable OAuth Client ID/Application ID

In Microsoft Entra, configure the client secret and enter it in Lovable.

Go to Certificates & secrets → New client secret.
Create a secret, and copy the secret value immediately (it won’t be shown again).
Paste the Microsoft Entra Client secret → Lovable OAuth Client Secret

Configure display name and SSO login identifier (tenant ID)

In Lovable, update these values as desired. The values are prepopulated based on your verified domain.

Display name: The name shown to users during authentication.
SSO login identifier (tenant ID): The URL users will use to sign in directly with SSO.

(Optional) Test configuration in Lovable

In Lovable, click Test configuration. If you configured everything accurately, the validation should be successful.

Finish OIDC provider configuration in Lovable

In Lovable, click Configure provider to finish the configuration of Microsoft Entra ID as your OIDC SSO provider.

Create an enterprise app in Microsoft Entra ID

Go to Microsoft Entra ID admin center → Enterprise applications, and select New application.
Select Create your own application and choose Integrate any other application you don’t find in the gallery (Non-gallery).
Give the app a name, for example Lovable SAML SSO.
Click Create. Your application is now created.

Configure SAML SSO

In Microsoft Entra, navigate to the Single sign-on setup page and select SAML. Under Basic SAML Configuration, enter the following:

Identifier (Entity ID): https://auth.lovable.dev/__/auth/handler
Reply URL (Assertion Consumer Service URL): https://auth.lovable.dev/__/auth/handler

Leave the other values blank and select Save.

To let users sign in to Lovable from the Microsoft My Apps portal, add a second Reply URL (Assertion Consumer Service URL): https://api.lovable.dev/sso/saml/idp-consume, and select it as the Default reply URL. See Set up IdP-initiated sign-in (SAML) for requirements.

Provide Lovable with your IdP information

When the application is set up in Microsoft Entra, you can choose between quick SAML provider setup or manual configuration in Lovable.Option 1: Quick setup - import from metadata URL

In Microsoft Entra, go to SAML Certificates and copy the App Federation Metadata URL.
In Lovable, paste the App Federation Metadata URL in Quick setup: Import from Metadata URL field.
Click Test & Import to automatically populate the required fields below.

Option 2: Manual configurationCopy the following values in Microsoft Entra and enter them in Lovable.

Microsoft Entra Login URL → Lovable SAML SSO Sign-on URL from your IdP
Microsoft Entra Microsoft Entra Identifier → Lovable Identity Provider Entity ID / Issuer
Microsoft Entra X509Certificate → Lovable X.509 Signing Certificate (public key)
You can download the certificate (Base 64) or open the App Federation Metadata URL in a new tab and copy the X509Certificate value. Paste the certificate value between the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines.

Configure display name and SSO login identifier (tenant ID)

In Lovable, update these values as desired. The values are prepopulated based on your verified domain.

Display name: The name shown to users during authentication.
SSO login identifier (tenant ID): The URL users will use to sign in directly with SSO.

Finish SAML provider configuration in Lovable

In Lovable, click Configure SAML Provider → Confirm & Enable SSO to finish the configuration of Microsoft Entra ID as your SAML SSO provider.

Configure other providers

You can configure any OIDC or SAML-compliant provider with Lovable SSO. Before you begin, complete Start SSO setup in Lovable to get the settings and values you need to use in your IdP.

OIDC
SAML

Provider mappingCommon field names across providers:

Redirect URI: Callback URL, Sign-in redirect URI
Issuer/Domain: Issuer URL, Authority, Okta domain, Auth0 domain, Tenant domain
Client credentials: Client ID and Client Secret

Steps

Create an OIDC confidential app

Create a new OIDC Web application in your identity provider.

Configure redirect URI

In Redirect/Callback URLs, add https://auth.lovable.dev/__/auth/handler

Enable required scopes

Ensure openid and email scopes are enabled and consented if needed.

Provide Lovable with your IdP information

In your IdP, locate the corresponding values and enter them in Lovable:

Domain or Issuer URL → Lovable OIDC Issuer URL/Discovery Endpoint
Client ID → Lovable OAuth Client ID/Application ID
Client Secret → Lovable OAuth Client Secret

Configure display name and SSO login identifier (tenant ID)

In Lovable, update these values as desired. The values are prepopulated based on your verified domain.

Display name: The name shown to users during authentication.
SSO login identifier (tenant ID): The URL users will use to sign in directly with SSO.

Provider mappingCommon field names across providers:

ACS URL: Single Sign-On URL, SSO URL, Reply URL, Assertion Consumer Service URL
Audience: SP Entity ID, Audience URI, Identifier
Attribute mapping: Attribute Statements, User Attributes & Claims

Steps

Create a SAML 2.0 application

Create a new SAML 2.0 application in your provider.

Configure endpoints

ACS URL: https://auth.lovable.dev/__/auth/handler
Audience / Entity ID: https://auth.lovable.dev/__/auth/handler

Map attributes

Ensure email is included in the SAML assertion. displayName is optional.

Assign users

Assign the application to users/groups who should access Lovable.

Provide Lovable with your IdP information

In Lovable, choose between quick SAML provider setup or manual configuration:Option 1: Quick setup - import from metadata URL

In your IdP, locate your SAML metadata URL (typically found in the SAML application settings or metadata details)
In Lovable, paste the metadata URL in Quick setup: Import from Metadata URL field.
Click Test & Import to automatically populate the required fields below.

Option 2: Manual configurationIn your IdP, locate the corresponding values and enter them in Lovable:

Login URL → Lovable SAML SSO Sign-on URL from your IdP
Identifier/Issuer/Entity ID → Lovable Identity Provider Entity ID / Issuer
X509Certificate → Lovable X.509 Signing Certificate (public key)

Configure display name and SSO login identifier (tenant ID)

In Lovable, update these values as desired. The values are prepopulated based on your verified domain.

Display name: The name shown to users during authentication.
SSO login identifier (tenant ID): The URL users will use to sign in directly with SSO.

With IdP-initiated SSO, users start sign-in from your identity provider’s app portal (for example, an Okta dashboard tile or the Microsoft My Apps portal) instead of from Lovable. IdP-initiated sign-in is optional and available for SAML providers on Business and Enterprise plans. It requires no additional configuration in Lovable. SP-initiated sign-in from Lovable keeps working as long as your IdP app still accepts the standard ACS URL (https://auth.lovable.dev/__/auth/handler); if your provider has only one ACS URL field, use a dedicated app for IdP-initiated sign-in so both flows keep working.

Requirements

A configured SAML SSO provider. OIDC providers support SP-initiated sign-in only.
Your workspace is the only workspace that has verified your email domain. IdP-initiated sign-in is disabled automatically while another workspace has the same domain verified.
Your IdP signs the SAML response (or the assertion within it) and scopes it to the Lovable SP Entity ID (https://auth.lovable.dev/__/auth/handler) through an Audience Restriction.

When a requirement is not met (for example, a second workspace verifies the same email domain), IdP-initiated sign-in stops working and users see an error page such as Forbidden or Unauthorized. Sign-in from Lovable is not affected, and you can switch back to SP-initiated sign-in only at any time. See Troubleshooting.

Configure your SAML app (or a dedicated IdP-initiated app) to post the SAML response to the IdP-initiated ACS URL: https://api.lovable.dev/sso/saml/idp-consume Keep the SP Entity ID / Audience URI unchanged: https://auth.lovable.dev/__/auth/handler.

Okta
Microsoft Entra ID
Auth0 and other providers

The Lovable app in the Okta App Catalog does not support IdP-initiated sign-in yet. Its SAML settings are pre-configured and cannot be changed. For now, users signing in through Okta must start sign-in from Lovable.

In your Lovable SAML enterprise application, go to Single sign-on → Basic SAML Configuration.
Add https://api.lovable.dev/sso/saml/idp-consume as an additional Reply URL (Assertion Consumer Service URL) and select it as the Default reply URL. Microsoft Entra sends IdP-initiated responses to the default reply URL.
Keep the Identifier (Entity ID) as https://auth.lovable.dev/__/auth/handler, and select Save.
Users can now sign in to Lovable from the My Apps portal.

In your SAML application, set the ACS URL used for IdP-initiated sign-in to https://api.lovable.dev/sso/saml/idp-consume. Providers also call this field Single sign-on URL, Reply URL, or Assertion Consumer Service URL. In Auth0, it is the Application Callback URL in the SAML2 Web App addon; the addon has a single callback URL, so create a dedicated Auth0 application for IdP-initiated sign-in.
Keep the Audience / Entity ID as https://auth.lovable.dev/__/auth/handler.
Make sure your provider signs SAML responses or assertions.

IdP-initiated sign-in is optional. If it does not work for your setup, point your SAML app back to https://auth.lovable.dev/__/auth/handler. This disables IdP-initiated sign-in, and users sign in from Lovable as usual. See Troubleshooting.

Map IdP groups to workspace roles

You can map the groups your identity provider sends in its sign-in claims to Lovable workspace roles, so people land at the right role automatically, and optionally restrict SSO sign-in to mapped groups only. Mappings can also add members to your workspace groups; see Add members to workspace groups automatically. Group mappings work with both OIDC and SAML providers on Business and Enterprise plans. To manage group mappings, go to Identity (Settings → Access → Identity), click your SSO provider, and open the Groups tab. There you can:

Map an IdP group to a workspace role. Enter the group name as your IdP sends it and choose a role (viewer, editor, or admin). Users whose sign-in includes a matching group claim get that role when they join. Matching between claims and mappings is case-insensitive, and if several mapped groups match, the highest-privilege role wins. A group mapping can never grant the owner role.
Turn on Group restriction. With the toggle off, matched users get their group’s role and everyone else signs in with the provider’s default JIT role. With the toggle on, only users whose IdP group matches one of your mappings can sign in through the provider; everyone else is denied.

Your IdP must include group information in its sign-in claims for mappings to match. See Send group claims from your IdP.Role mapping and group membership sync also require SSO sign-in (JIT) provisioning to be enabled. With JIT disabled, matched users sign in without receiving a mapped role or group membership; Group restriction still applies either way.

Add members to workspace groups automatically

Group mappings also provision group membership. When a user signs in through SSO with a group claim that matches a mapping, and your workspace has a group with the same name as that mapping, Lovable adds the user to that group.

Groups are matched by name. The mapping name must match the Lovable group name exactly, including capitalization. In the Groups tab, your existing workspace groups appear as suggestions, so you can add mappings that match them exactly.
No matching group means no membership. If your workspace has no group with the same name, the mapping is used for role provisioning only: matching users still get the mapped role, but no group membership is created.
Lovable never creates groups from claims. Groups control access to projects, folders, and published apps, so creating them stays a deliberate admin action. To sync membership for a group, first create it in Groups (Settings → Access → Groups), then add a mapping with the same name.
Membership is only added, never removed. Lovable does not remove anyone from a group based on sign-in claims; remove members from groups manually if needed. To manage the full group lifecycle from your IdP, including removals, use SCIM provisioning on the Enterprise plan.

Send group claims from your IdP

Lovable reads groups from a claim named groups in the sign-in response, for both OIDC and SAML providers. The default SAML group claim names used by Microsoft Entra ID (http://schemas.microsoft.com/ws/2008/06/identity/claims/groups) and AD FS (http://schemas.xmlsoap.org/claims/Group) are also recognized, so you can keep those defaults. The claim must contain group names, not group IDs. Send names as multiple attribute values, or as a single value separated by commas or semicolons.

Okta
Microsoft Entra ID
Other providers

Configure the group claim on your Lovable app in the Okta Admin Console.SAMLWhere the group attribute is configured depends on how you added the Lovable app:

App Catalog app: the app’s SAML settings are pre-configured and cannot be edited. Open the app’s Sign On tab and look for a Group Attribute Statements section there. If the app doesn’t offer one, it cannot send group claims: use the Lovable OIDC app instead, or create a custom SAML app following Configure other providers.
Custom SAML app: open the app’s General tab and click Edit under SAML Settings.

Add a group attribute statement with:

Name: groups
Name format: Unspecified
Filter: a filter matching the groups to send, for example Matches regex .* to send all of the user’s groups.

Save your changes.OIDC

Open your Lovable OIDC app and go to the Sign On tab.
Under OpenID Connect ID Token, click Edit and set Groups claim type to Filter.
Set the groups claim name to groups with a filter matching the groups to send, for example Matches regex .*.
Save your changes.

Okta sends group names in the claim, so values match your mappings as long as the names line up.

In your Lovable enterprise application, go to Single sign-on → Attributes & Claims → Edit.
Click Add a group claim.
Choose which groups to include. Groups assigned to the application is recommended: it sends only the groups assigned to the Lovable app and avoids token size limits.
Set Source attribute to an option that emits group names, such as Cloud-only group display names, or sAMAccountName for groups synced from on-premises Active Directory.
Save the claim. You can keep the default claim name: Lovable recognizes Microsoft Entra’s default group claim.

By default, Microsoft Entra ID sends group object IDs (GUIDs) instead of names. Object IDs never match name-based mappings, so make sure the claim’s source attribute emits group names.

In your SAML or OIDC application, include a group attribute or claim named groups in the sign-in response.
Make sure the values are group names (not IDs) and cover the groups you mapped in Lovable.

Delete an SSO provider

To remove your workspace SSO provider, go to Identity (Settings → Access → Identity), find the provider, and click Delete. Because a workspace can only have one SSO provider, deleting it retires the whole SSO setup. Lovable shows a Delete SSO provider confirmation dialog that lists exactly what will be turned off, based on what your workspace currently has configured:

Turn off Enforce SSO: members can sign in again with email/password or third-party login.
Remove SCIM provisioning: the SCIM API key is revoked and SCIM-managed groups are deleted. Existing workspace members are not removed. See Set up SCIM user provisioning.
Disable the domain lock: people with emails on your verified domains can sign up without SSO again.
Delete IdP group role mappings: IdP groups will no longer grant workspace roles when users sign in.

The dialog shows a line for each of these only when it applies to your workspace, along with the number of IdP group role mappings that will be removed.

Deleting a provider cannot be undone. To use SSO again, you need to reconfigure the provider from scratch; its previous configuration is not retained.

Members keep their workspace access after the provider is deleted. Members whose only sign-in method was that provider can recover their account themselves at the next sign-in; see Recover access after an SSO provider is removed. Each side effect is recorded in the audit log: both the SSO provider removed entry (with the exact settings that were turned off) and, when SCIM was configured, a separate SCIM disabled entry.

Troubleshooting

OIDC
SAML

Invalid or mismatched Redirect URI

Ensure the redirect/callback URL exactly matches https://auth.lovable.dev/__/auth/handler in your IdP.

Issuer URL / discovery fails

Use the provider’s OIDC Issuer URL (not just the domain).

For Okta, copy from the Sign-on tab
For Auth0, use your tenant domain.

Email not returned

Grant the email scope and ensure the user account has a primary email.

Authorization flow issues

Use Authorization Code with a confidential client and client secret. Avoid implicit or PKCE-only app types.

Invalid ACS or Audience

Ensure both ACS and Audience/Entity ID exactly match https://auth.lovable.dev/__/auth/handler in your IdP.

Email claim missing

Make sure to map an email claim.For Microsoft Entra ID, map email to user.mail. If user.mail is empty, use user.userprincipalname.

Provider credentials invalid

Paste the correct X.509 certificate. If the certificate rotates, update it in Lovable.

Group mappings don't match

If users get the default role instead of their mapped role, or Group restriction denies people it shouldn’t:

Make sure the assertion includes a group attribute named groups (Microsoft Entra ID’s and AD FS’s default group claim names also work). See Send group claims from your IdP.
Make sure the claim contains group names, not IDs. Microsoft Entra ID sends object IDs unless the group claim’s source attribute is set to emit names.
Claim matching is case-insensitive, but the names must otherwise match your mappings exactly.
Make sure SSO sign-in (JIT) provisioning is enabled. With it disabled, users sign in without receiving mapped roles or group memberships.

If starting sign-in from your IdP’s app portal shows an error page (for example, Forbidden or Unauthorized):

Make sure your email domain is verified in only one Lovable workspace. IdP-initiated sign-in is disabled automatically while more than one workspace has verified the same domain.
Make sure your IdP signs the SAML response (or the assertion within it) and the Audience Restriction matches https://auth.lovable.dev/__/auth/handler.
If your provider restricts access by group, make sure the user’s SAML assertion includes a matching group claim. This also applies when signing in from Lovable.
If sign-in still fails, change the ACS URL in your IdP app back to https://auth.lovable.dev/__/auth/handler. This disables IdP-initiated sign-in and restores SP-initiated sign-in from Lovable. IdP-initiated sign-in is optional, so you can stay on SP-initiated sign-in only and try again once the requirements are met.

Recover access after an SSO provider is removed

Workspace members who only ever signed in through the deleted SSO provider can recover access themselves from the standard Lovable login page, with no admin action or support request required. When they enter their email on the login page, Lovable detects that their only sign-in method was the removed provider and shows a recovery panel:

If the workspace has a replacement SSO provider on the same verified domain, the panel shows Reconnect your account with a sign-in button for the new provider. Clicking it signs the user in with that provider and links the new identity to their existing account, so their projects, roles, and history are preserved. If linking cannot happen automatically (for example, the new provider does not verify the same email), the panel falls back to the password path below.
If there is no replacement SSO provider, the panel shows Set a password for your account and offers to email a link. The user opens the link, sets a password, and signs in with email + password from then on. This uses the same mechanism as a normal password reset, framed as adding a password because the old SSO sign-in was removed.

Users with any other working sign-in method (password, Google, GitHub, Apple, or another still-valid SSO provider) are not affected and continue to sign in normally.

FAQ

I already have an account, but I'm joining a business workspace that uses SSO. How do I log in?

If you created your account using another login method (like email/password, Google, or GitHub), you need to log in that way first. Once you’re logged in, navigate to Settings → Your account → Link SSO. This will link your existing account to your company SSO.

Important: If you attempt to log in with SSO before linking your existing account, you’ll see an error. This is a security measure to prevent unauthorized access. Log in using your original method first to complete the linking process.

No. Forgot password? only works for accounts that have an email and password sign-in method.If your account signs in through Google, GitHub, Apple, or a SAML/OIDC SSO provider, Lovable does not send a password reset email and shows a Password reset unavailable message, because completing a reset would add a password to an account that is meant to sign in through your provider. Reset your credentials with your identity provider instead (for example, Google Account recovery or your company IdP).

Exception for deleted SSO providers: if your only sign-in method was an SSO provider that has since been removed from your workspace, you can set a password for the first time through the recovery flow on the login page. See Recover access after an SSO provider is removed.

Which SSO providers does Lovable support?

Lovable supports the industry-standard OIDC and SAML protocols, so you can integrate with any SSO provider that supports them.

Does Lovable support multiple SSO providers per workspace?

No. A workspace can have one active SSO provider configured at a time.

Can I enforce SSO for my workspace?

Yes. The workspace owner or admin can enable Enforce SSO in Identity (Settings → Access → Identity) and choose the session duration to configure how long users stay signed in before requiring re-authentication (8 hours, 24 hours, 48 hours, or 7 days).This requires all workspace members to use SSO for authentication. External collaborators and invite links will be disabled.

Does Lovable support IdP-initiated SSO?

Yes. SAML providers can optionally enable IdP-initiated sign-in: users start sign-in from your IdP’s app portal once your SAML app posts the SAML response to https://api.lovable.dev/sso/saml/idp-consume. It only works while your workspace is the only workspace that has verified your email domain, and SP-initiated sign-in from Lovable keeps working either way. See Set up IdP-initiated sign-in (SAML).OIDC providers support SP-initiated sign-in only: users must start sign-in from Lovable.

An error page such as Forbidden or Unauthorized means the requirements are not met. First, make sure your email domain is verified in only one Lovable workspace. IdP-initiated sign-in is disabled automatically while more than one workspace has verified the same domain.If sign-in still fails, change the ACS URL in your IdP app back to https://auth.lovable.dev/__/auth/handler. IdP-initiated sign-in is optional: users sign in from Lovable as usual, and you can try again once the requirements are met.

Does Lovable support just-in-time (JIT) provisioning with SSO?

Yes, Lovable supports JIT (just-in-time) provisioning through SSO. User accounts are created automatically the first time someone signs in via SSO, and they’re added to your company workspace.You can also set a default role for JIT-created users (admin, editor, or viewer) that will be applied when they join via SSO for the first time.On Enterprise plans, workspace owners and admins can toggle SSO JIT themselves from the SSO sign-in row in Identity (Settings → Access → Identity → User provisioning). The toggle appears once an SSO provider is configured.On Business plans, SSO JIT is automatically enabled when an SSO provider is configured, and the row shows a read-only Enabled or Disabled status. Contact Lovable support if you need it changed. See Manage workspace identity and user provisioning for how the provisioning options work together.

What happens to existing members when I set up group mappings?

Existing members keep their current role. Group-to-role mappings are applied when someone joins the workspace through SSO; if several mapped groups match, the highest-privilege role wins.On each SSO sign-in, members are also added to any workspace groups whose names match their IdP group claims. Lovable never removes anyone from a group automatically; remove members from groups manually if needed.Turning on Group restriction does affect existing members: anyone signing in through the provider without a matching group claim is denied, so make sure your mappings cover everyone who should keep access. See Map IdP groups to workspace roles.

Does Lovable create workspace groups from IdP group claims?

No. Group claims never create groups in Lovable; they are used for provisioning only. If a mapping matches but your workspace has no group with the same name, matching users still get the mapped role, but no group membership is created.To sync membership, create the group in Groups (Settings → Access → Groups) first, using the same name as your mapping. Lovable then adds matching users to it when they sign in through SSO. See Add members to workspace groups automatically.

Does Lovable support SCIM or automatic user provisioning?

Yes. Lovable supports SCIM provisioning for automated user provisioning and deprovisioning on the Enterprise plan.With SCIM, user creation, removal, and role assignment are managed centrally from your identity provider based on assignments and group membership.See Set up SCIM user provisioning for more information.

Your tenant ID is the {tenantId} value used in your SSO login URL:
https://lovable.dev/sso-login/{tenantId}. It matches the SSO login identifier you configured when setting up your SSO provider in Lovable.You can also find it in Identity (Settings → Access → Identity) after you have configured your provider.

How can I edit my SSO provider configuration?

You can change a provider’s display name, SSO login identifier, and JIT default role at any time by clicking the provider in Identity (Settings → Access → Identity).Credentials and protocol settings (issuer, client ID and secret, certificates) cannot be edited. To change those, delete the existing SSO provider and configure it again.

Deleting the provider also turns off Enforce SSO, removes SCIM provisioning (revoking the SCIM API key and deleting SCIM-managed groups), disables the verified-domain lock, and deletes any IdP group role mappings. The delete dialog lists exactly which of these apply before you confirm. See Delete an SSO provider.

What happens to users who only signed in via SSO if we delete the provider?

They keep their workspace access and can recover their account themselves from the login page: either by signing in through a replacement SSO provider (Lovable links the new identity to their existing account) or by setting a password through an emailed link. See Recover access after an SSO provider is removed.

Getting started

Build

Connect

Collaborate

Deploy & host

Grow & optimize

Workspace & account

Plans & billing

Guides & reference

Set up workspace single sign-on (SSO)

Supported SSO protocols

Prerequisites

Start SSO setup in Lovable

IdP configuration reference

Provider-specific setup guides

Configure Okta as your SSO provider

Configure Auth0 as your SSO provider

Configure Microsoft Entra ID as your SSO provider

Configure other providers

Requirements

Map IdP groups to workspace roles

Add members to workspace groups automatically

Send group claims from your IdP

Delete an SSO provider

Troubleshooting

FAQ

​Supported SSO protocols

​Prerequisites

​Start SSO setup in Lovable

​IdP configuration reference

​Provider-specific setup guides

​Configure Okta as your SSO provider

​Configure Auth0 as your SSO provider

​Configure Microsoft Entra ID as your SSO provider

​Configure other providers

​Set up IdP-initiated sign-in (SAML)

​Requirements

​Enable IdP-initiated sign-in

​Map IdP groups to workspace roles

​Add members to workspace groups automatically

​Send group claims from your IdP

​Delete an SSO provider

​Troubleshooting

​FAQ

Supported SSO protocols

Prerequisites

Start SSO setup in Lovable

IdP configuration reference

Provider-specific setup guides

Configure Okta as your SSO provider

Configure Auth0 as your SSO provider

Configure Microsoft Entra ID as your SSO provider

Configure other providers

Set up IdP-initiated sign-in (SAML)

Requirements

Enable IdP-initiated sign-in

Map IdP groups to workspace roles

Add members to workspace groups automatically

Send group claims from your IdP

Delete an SSO provider

Troubleshooting

FAQ