Skip to content

Set up workspace single sign-on (SSO)

Connect Okta, Auth0, Microsoft Entra ID, or any OIDC/SAML 2.0 provider to enable secure, centralized authentication for your workspace.

Updated View as Markdown

<head> <script type=“application/ld+json”> {{"@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [{"@type": "Question", "name": "I already have an account, but I'm joining a business workspace that uses SSO. How do I log in?", "acceptedAnswer": {"@type": "Answer", "text": "If you created your account using another login method (such as email and password, Google, or GitHub), you need to log in that way first. When you're logged in, go to Settings → Your account → Linked accounts and click Link account under Link company account, then sign in with your company SSO. This links 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."}}, {"@type": "Question", "name": "Can members who sign in with SSO use 'Forgot password?' on the login page?", "acceptedAnswer": {"@type": "Answer", "text": "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, RShift Sites does not send a password reset email and shows a Password reset unavailable message. Reset your credentials with your identity provider instead. Exception: 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."}}, {"@type": "Question", "name": "Which SSO providers does RShift Sites support?", "acceptedAnswer": {"@type": "Answer", "text": "RShift Sites supports the industry-standard OIDC and SAML protocols, so you can integrate with any SSO provider that supports them."}}, {"@type": "Question", "name": "Does RShift Sites support multiple SSO providers per workspace?", "acceptedAnswer": {"@type": "Answer", "text": "No. A workspace can have one active SSO provider configured at a time."}}, {"@type": "Question", "name": "Can I enforce SSO for my workspace?", "acceptedAnswer": {"@type": "Answer", "text": "Yes. The workspace owner or admin can enable Enforce SSO in Settings → Access → Identity and choose the Session duration that sets how long users stay signed in before RShift Sites requires a new SSO sign-in (8 hours, 24 hours, 48 hours, or 7 days). All workspace members must then sign in through SSO. When you enable it, RShift Sites asks whether to remove external collaborators from your projects. Invite links keep working only for people whose email is on one of your verified domains. Test an SSO sign-in first: for six hours after you add a provider, the Enforce SSO toggle stays disabled and shows Wait 6 hours and test SSO login before enforcing SSO."}}, {"@type": "Question", "name": "Does RShift Sites support IdP-initiated SSO?", "acceptedAnswer": {"@type": "Answer", "text": "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 RShift Sites 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 RShift Sites."}}, {"@type": "Question", "name": "What should I do if IdP-initiated sign-in shows an error?", "acceptedAnswer": {"@type": "Answer", "text": "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 RShift Sites 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 RShift Sites as usual, and you can try again when the requirements are met."}}, {"@type": "Question", "name": "Does RShift Sites support just-in-time (JIT) provisioning with SSO?", "acceptedAnswer": {"@type": "Answer", "text": "Yes. When SSO JIT is on, user accounts are created automatically the first time someone signs in via SSO, and they’re added to your company workspace. You can set the provider's Default role for new members (Viewer, Editor, or Admin). If you don't change it, JIT-created users join as an Editor. On Enterprise plans, workspace owners and admins can enable or disable SSO JIT from the SSO sign-in row in Settings → Access → Identity → User provisioning 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."}}, {"@type": "Question", "name": "What happens to existing members when I set up group mappings?", "acceptedAnswer": {"@type": "Answer", "text": "Existing members keep their current role. RShift Sites applies group-to-role mappings 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. RShift Sites never removes anyone from a group automatically. Enabling Group restriction affects 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."}}, {"@type": "Question", "name": "Does RShift Sites create workspace groups from IdP group claims?", "acceptedAnswer": {"@type": "Answer", "text": "Yes, for mapped groups. When a sign-in matches a mapping and your workspace has no group with that name, RShift Sites creates the group and adds the user to it. Unmapped group claims never create groups, and RShift Sites does not create groups from sign-in claims when your workspace groups come from SCIM provisioning."}}, {"@type": "Question", "name": "Does RShift Sites support SCIM or automatic user provisioning?", "acceptedAnswer": {"@type": "Answer", "text": "Yes. RShift Sites 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."}}, {"@type": "Question", "name": "How can I find my tenant ID (SSO login identifier)?", "acceptedAnswer": {"@type": "Answer", "text": "Your tenant ID is the {tenantId} value in your SSO login URL, https://lovable.dev/sso-login/{tenantId}. It is your verified domain with dots replaced by hyphens, plus the optional Login URL suffix you entered during setup. After setup, the full URL appears in the SSO providers row in Settings → Access → Identity and in the provider's Login URL field."}}, {"@type": "Question", "name": "How can I edit my SSO provider configuration?", "acceptedAnswer": {"@type": "Answer", "text": "Click the provider in Settings → Access → Identity to open its settings. On the General tab you can change the Display name, the Login URL suffix, and the Default role for new members, then click Save changes. The Connection tab lets you change the SAML sign-on URL and signing certificates, or enter a new OIDC client secret and its expiration date. The Groups tab includes your group mappings and the Group restriction toggle. You cannot edit the issuer, entity ID, or client ID. 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."}}, {"@type": "Question", "name": "What happens to users who only signed in via SSO if we delete the provider?", "acceptedAnswer": {"@type": "Answer", "text": "They keep their workspace access and can recover their account themselves from the login page: either by signing in through a replacement SSO provider (RShift Sites links the new identity to their existing account) or by setting a password through an emailed link."}}]}} </script> </head>

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

Supported SSO protocols

RShift Sites 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 OAuth 2.0 that verifies who is signing in.
  • 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 RShift Sites using OIDC or SAML, you need:

  • IdP admin access (Okta, Auth0, Microsoft Entra ID, or any other provider you’re using)
  • Workspace owner or admin role in RShift Sites
  • A verified domain in RShift Sites, to prove domain ownership

Start SSO setup in RShift Sites

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

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

The workspace owner or admin can set up SSO. To start, go to Identity (Settings → Access → Identity) and click Add provider in the SSO providers section. On the Choose SSO Protocol screen, click Configure OIDC or Configure SAML.

The setup then runs in three stages:

  1. Preparation. RShift Sites shows what to configure in your IdP, such as the app type, scopes, and attribute mappings, and the RShift Sites URLs to copy into your IdP. The values are listed in the reference below.
  2. Configuration. You enter your IdP’s issuer and client credentials or certificates, a display name, and the verified domain your login URL is based on. The provider guides below list the exact fields.
  3. Test and confirm. For OIDC, Test configuration checks your values before you continue. Both protocols end on a confirmation page where you click Confirm & enable SSO.

IdP configuration reference

Use these values while configuring OIDC or SAML in your IdP. RShift Sites shows the same values on the preparation screens, with copy buttons on the URLs.

OIDC

  • Application type: Web Application or Server-side 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

SAML

  • 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:
      • displayName (recommended): map to user’s full name
      • photoURL (recommended): map to user’s profile picture URL
      • Email is not a separate attribute. RShift Sites reads it from the Name ID, so the Name ID source must be the user’s email address, not a login identifier.
    • Protocol settings:
      • Name ID format: EmailAddress
      • Signature algorithm: RSA-SHA256
      • SAML binding: HTTP-POST
      • Response signed: yes

Your SSO login URL

Each provider gets a login URL that members can use to sign in with SSO directly: https://lovable.dev/sso-login/{tenantId}. The {tenantId} part is your verified domain with dots replaced by hyphens, for example acme-com for acme.com. If you enter a Login URL suffix during setup, RShift Sites appends it, for example acme-com-engineering. Login identifiers are unique across RShift Sites, so a second workspace on the same domain needs a suffix. After setup, the URL appears in the SSO providers row and in the provider’s Login URL field, each with a copy button.

Enforce SSO

Enforce SSO requires an active SSO session to use the workspace. Members who sign in another way are asked to sign in through your provider before they can access it. The toggle in Identity (Settings → Access → Identity) becomes available when your workspace has a verified domain and an SSO provider. Test an SSO sign-in before you enable it: for six hours after you add a provider, the toggle stays disabled and shows Wait 6 hours and test SSO login before enforcing SSO.

When you enable the toggle, RShift Sites opens the Enable enforce SSO dialog:

  • Keep Remove all external collaborators selected and click Enable and remove to remove external collaborators from every project in the workspace.
  • Clear it and click Enable to keep them. RShift Sites then sets the external collaborator level to allow all collaborators. You can change it later in Settings → Security → Privacy & security. See Privacy and security settings.

While SSO is enforced, invite links only work for people whose email is on one of your verified domains. Use Session duration to choose how long members stay signed in before RShift Sites requires a new SSO sign-in: 8 hours, 24 hours, 48 hours, or 7 days.

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 RShift Sites 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

Add the RShift Sites app in Okta

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

Provide RShift Sites with your IdP information

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

  • Okta Issuer URL → RShift Sites OIDC Issuer URL / Discovery Endpoint
  • Okta Client ID → RShift Sites OAuth Client ID / Application ID
  • Okta Client Secret → RShift Sites OAuth Client Secret
  • Optionally, the date the client secret expires → RShift Sites Client secret expiration (optional)

Configure the display name and login URL

In RShift Sites, fill in the remaining fields:

  • Display Name: The name shown to users during authentication.
  • Verified domain: The verified domain your login URL is based on. RShift Sites preselects it when you have only one.
  • Login URL suffix (optional): An addition to the login URL, for example engineering. RShift Sites shows the resulting URL below the field. See Your SSO login URL.

Test the configuration in RShift Sites

In RShift Sites, click Test configuration. RShift Sites checks the issuer, client ID, and client secret and shows the outcome on the Test results screen. Fix anything it reports, then click Configure provider.

Finish OIDC provider configuration in RShift Sites

In RShift Sites, review the confirmation page, then click Confirm & enable SSO to finish the configuration of Okta as your OIDC SSO provider.

SAML

Add the RShift Sites app in Okta

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

Provide RShift Sites with your IdP information

In RShift Sites, 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 RShift Sites application, scroll to Metadata details, and copy the Metadata URL.
  • In RShift Sites, 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 configuration

Open the metadata URL in a new tab. Copy the following values and enter them in RShift Sites.

  • Okta SingleSignOnService Location → RShift Sites SAML SSO Sign-on URL (from your IdP)
  • Okta EntityID → RShift Sites Identity Provider Entity ID / Issuer
  • Okta X509Certificate → RShift Sites X.509 signing certificates

Configure the display name and login URL

In RShift Sites, fill in the remaining fields:

  • Display Name: The name shown to users during authentication.
  • Verified domain: The verified domain your login URL is based on. RShift Sites preselects it when you have only one.
  • Login URL suffix (optional): An addition to the login URL, for example engineering. RShift Sites shows the resulting URL below the field. See Your SSO login URL.

Finish SAML provider configuration in RShift Sites

In RShift Sites, click Configure SAML provider, review the confirmation page, then click Confirm & enable SSO to finish the configuration of Okta as your SAML SSO provider.

Configure Auth0 as your SSO provider

OIDC

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 RShift Sites 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 RShift Sites with your IdP information

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

  • Auth0 Domain → RShift Sites OIDC Issuer URL / Discovery Endpoint (include https://)
  • Auth0 Client ID → RShift Sites OAuth Client ID / Application ID
  • Auth0 Client Secret → RShift Sites OAuth Client Secret
  • Optionally, the date the client secret expires → RShift Sites Client secret expiration (optional)

Configure the display name and login URL

In RShift Sites, fill in the remaining fields:

  • Display Name: The name shown to users during authentication.
  • Verified domain: The verified domain your login URL is based on. RShift Sites preselects it when you have only one.
  • Login URL suffix (optional): An addition to the login URL, for example engineering. RShift Sites shows the resulting URL below the field. See Your SSO login URL.

Test the configuration in RShift Sites

In RShift Sites, click Test configuration. RShift Sites checks the issuer, client ID, and client secret and shows the outcome on the Test results screen. Fix anything it reports, then click Configure provider.

Finish OIDC provider configuration in RShift Sites

In RShift Sites, review the confirmation page, then click Confirm & enable SSO to finish the configuration of Auth0 as your OIDC SSO provider.

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 RShift Sites 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 RShift Sites with your IdP information

In RShift Sites, 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 RShift Sites, 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 configuration

In Auth0 → Addon: SAML2 Web app → Usage, copy the following SAML Protocol Configuration Parameter values and enter them in RShift Sites.

  • Auth0 Identity Provider Login URL → RShift Sites SAML SSO Sign-on URL (from your IdP)
  • Auth0 Issuer → RShift Sites Identity Provider Entity ID / Issuer
  • Auth0 Identity Provider Certificate (X509Certificate) → RShift Sites X.509 signing certificates

Configure the display name and login URL

In RShift Sites, fill in the remaining fields:

  • Display Name: The name shown to users during authentication.
  • Verified domain: The verified domain your login URL is based on. RShift Sites preselects it when you have only one.
  • Login URL suffix (optional): An addition to the login URL, for example engineering. RShift Sites shows the resulting URL below the field. See Your SSO login URL.

Finish SAML provider configuration in RShift Sites

In RShift Sites, click Configure SAML provider, review the confirmation page, then click Confirm & enable SSO to finish the configuration of Auth0 as your SAML SSO provider.

Configure Microsoft Entra ID as your SSO provider

OIDC

Add the RShift Sites app in Microsoft Entra ID

  • In the Microsoft Entra admin center, go to Entra ID → Enterprise apps → New application.
    • In the Add from the gallery section, search for RShift Sites, select it in the results, and add it to your tenant.
    • Open the app, go to Single sign-on, and select Go to application to open the app’s registration.

Add the RShift Sites redirect URI

  • In the app’s registration, go to Authentication.
    • In Redirect URIs, add https://auth.lovable.dev/__/auth/handler.
    • Click Configure.

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, and check that the Microsoft Graph delegated permissions RShift Sites needs are listed:
    • email
    • openid
    • profile
    • To add any that are missing, click Add a permission → Microsoft Graph → Delegated permissions, select them, then click Add permissions.
    • Click Grant admin consent.

Create a client secret

  • In Microsoft Entra, go to Certificates & secrets → Client secrets → New client secret.
    • Enter a description, choose an expiry, and click Add. Note the expiration date so you can record it in RShift Sites.
    • Copy the secret Value immediately. It isn’t shown again after you leave the page.

Provide RShift Sites with your IdP information

In RShift Sites, enter the following:

  • OIDC Issuer URL / Discovery Endpoint: format the URL as https://login.microsoftonline.com/{TENANT_ID}/v2.0
  • Microsoft Entra Application (Client) ID, from the Overview page → RShift Sites OAuth Client ID / Application ID
  • The Microsoft Entra Client secret value you copied → RShift Sites OAuth Client Secret
  • Optionally, the date the client secret expires → RShift Sites Client secret expiration (optional)

Configure the display name and login URL

In RShift Sites, fill in the remaining fields:

  • Display Name: The name shown to users during authentication.
  • Verified domain: The verified domain your login URL is based on. RShift Sites preselects it when you have only one.
  • Login URL suffix (optional): An addition to the login URL, for example engineering. RShift Sites shows the resulting URL below the field. See Your SSO login URL.

Test the configuration in RShift Sites

In RShift Sites, click Test configuration. RShift Sites checks the issuer, client ID, and client secret and shows the outcome on the Test results screen. Fix anything it reports, then click Configure provider.

Finish OIDC provider configuration in RShift Sites

In RShift Sites, review the confirmation page, then click Confirm & enable SSO to finish the configuration of Microsoft Entra ID as your OIDC SSO provider.

SAML

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 RShift Sites 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.

Provide RShift Sites 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 RShift Sites.

Option 1: Quick setup - import from metadata URL

  • In Microsoft Entra, go to SAML Certificates and copy the App Federation Metadata URL.
  • In RShift Sites, 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 configuration

Copy the following values in Microsoft Entra and enter them in RShift Sites.

  • Microsoft Entra Login URL → RShift Sites SAML SSO Sign-on URL (from your IdP)
  • Microsoft Entra Microsoft Entra Identifier → RShift Sites Identity Provider Entity ID / Issuer
  • Microsoft Entra X509Certificate → RShift Sites X.509 signing certificates

Configure the display name and login URL

In RShift Sites, fill in the remaining fields:

  • Display Name: The name shown to users during authentication.
  • Verified domain: The verified domain your login URL is based on. RShift Sites preselects it when you have only one.
  • Login URL suffix (optional): An addition to the login URL, for example engineering. RShift Sites shows the resulting URL below the field. See Your SSO login URL.

Finish SAML provider configuration in RShift Sites

In RShift Sites, click Configure SAML provider, review the confirmation page, then click 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 RShift Sites SSO.

Before you begin, complete Start SSO setup in RShift Sites to get the settings and values you need to use in your IdP.

OIDC

Provider mapping

Common 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 RShift Sites with your IdP information

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

  • Domain or Issuer URL → RShift Sites OIDC Issuer URL / Discovery Endpoint
  • Client ID → RShift Sites OAuth Client ID / Application ID
  • Client Secret → RShift Sites OAuth Client Secret
  • Optionally, the date the client secret expires → RShift Sites Client secret expiration (optional)

Configure the display name and login URL

In RShift Sites, fill in the remaining fields:

  • Display Name: The name shown to users during authentication.
  • Verified domain: The verified domain your login URL is based on. RShift Sites preselects it when you have only one.
  • Login URL suffix (optional): An addition to the login URL, for example engineering. RShift Sites shows the resulting URL below the field. See Your SSO login URL.

Test the configuration in RShift Sites

In RShift Sites, click Test configuration. RShift Sites checks the issuer, client ID, and client secret and shows the outcome on the Test results screen. Fix anything it reports, then click Configure provider.

Finish OIDC provider configuration in RShift Sites

In RShift Sites, review the confirmation page, then click Confirm & enable SSO to finish the configuration of your OIDC SSO provider.

SAML

Provider mapping

Common 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 RShift Sites.

Provide RShift Sites with your IdP information

In RShift Sites, 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 RShift Sites, 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 configuration

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

  • Login URL → RShift Sites SAML SSO Sign-on URL (from your IdP)
  • Identifier/Issuer/Entity ID → RShift Sites Identity Provider Entity ID / Issuer
  • X509Certificate → RShift Sites X.509 signing certificates

Configure the display name and login URL

In RShift Sites, fill in the remaining fields:

  • Display Name: The name shown to users during authentication.
  • Verified domain: The verified domain your login URL is based on. RShift Sites preselects it when you have only one.
  • Login URL suffix (optional): An addition to the login URL, for example engineering. RShift Sites shows the resulting URL below the field. See Your SSO login URL.

Finish SAML provider configuration in RShift Sites

In RShift Sites, click Configure SAML provider, review the confirmation page, then click Confirm & enable SSO to finish the configuration of your SAML SSO provider.

Set up IdP-initiated sign-in (SAML)

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 RShift Sites. IdP-initiated sign-in is optional and available for SAML providers on Business and Enterprise plans. It requires no additional configuration in RShift Sites. SP-initiated sign-in from RShift Sites 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 RShift Sites SP Entity ID (https://auth.lovable.dev/__/auth/handler) through an Audience Restriction.

Enable IdP-initiated sign-in

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

  • In your RShift Sites 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 RShift Sites from the My Apps portal.

Auth0 and other providers

  • 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.

Map IdP groups to workspace roles

You can map the groups your identity provider sends in its sign-in claims to RShift Sites workspace roles, so people receive 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 in the Group column, choose a role (Viewer, Editor, or Admin), and click Add. Users whose sign-in includes a matching group claim get that role when they join. Claims must match mappings exactly, including capitalization. If several mapped groups match, the highest-privilege role wins. A group mapping you add here can never grant the owner role.
  • Enable Group restriction. While it is disabled, matched users get their group’s role and everyone else signs in with the provider’s Default role for new members (Editor if you haven’t changed it). While it is enabled, only users whose IdP group matches one of your mappings can sign in through the provider. Everyone else is denied.

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, RShift Sites adds the user to the workspace group with the same name as that mapping.

  • Groups are matched by name. The mapping name must match the RShift Sites group name exactly, including capitalization. As you type a group name in the Groups tab, RShift Sites suggests matching workspace groups under Existing groups. Click one to use its exact name.
  • RShift Sites creates the group if it does not exist. The first matching sign-in creates a workspace group named after the mapping and adds the user to it. Groups control access to projects, folders, and published apps, so review what a new group can access in Groups (Settings → Access → Groups). Unmapped group claims never create groups.
  • SCIM-managed groups are the exception. If your workspace groups come from SCIM provisioning, RShift Sites does not create groups from sign-in claims.
  • Membership is only added, never removed. RShift Sites does not remove anyone from a group based on sign-in claims. Remove members from groups yourself 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

RShift Sites 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

Configure the group claim on your RShift Sites app in the Okta Admin Console.

SAML

Where the group attribute is configured depends on how you added the RShift Sites 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 RShift Sites 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 RShift Sites 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.

Microsoft Entra ID

  • In your RShift Sites 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 RShift Sites 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: RShift Sites recognizes Microsoft Entra’s default group claim.

Other providers

  • 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 RShift Sites.

Manage an existing SSO provider

Workspace owners and admins can change a provider’s settings without deleting it. Go to Identity (Settings → Access → Identity) and click the provider in the SSO providers section. The provider dialog has three tabs:

  • General: the Display name, the Login URL suffix, and the Default role for new members.
  • Connection: the settings RShift Sites uses to verify sign-ins from your identity provider. For SAML, the Sign-on URL and the Signing certificates. For OIDC, a new Client secret and its expiration date. The identity provider entity ID, the issuer, and the client ID are read-only.
  • Groups: your group mappings and the Group restriction toggle. See Map IdP groups to workspace roles.

Your changes take effect when you click Save changes. Before RShift Sites saves a change on the Connection tab, it checks the values. For SAML, RShift Sites validates the sign-on URL and reads every certificate. For OIDC, RShift Sites contacts your provider to check the new client secret. If a check fails, RShift Sites shows the error and keeps the current configuration. If RShift Sites cannot reach your provider, or your provider does not support checking a secret in advance, RShift Sites saves the new secret and shows a warning that it could not check the secret. Your provider then checks the secret at the next sign-in. Each saved connection change appears in the audit log as SSO connection updated.

Rotate a SAML signing certificate

You can add up to 10 signing certificates to a SAML provider, and RShift Sites accepts sign-ins signed with any of them. When your identity provider issues a new signing certificate, paste it under Add a certificate on the Connection tab before your provider starts using it, so sign-in continues without interruption. Remove the old certificate with its delete icon after the switch. Each certificate shows its subject, fingerprint, and expiration date. RShift Sites warns when a certificate expires within 30 days and does not save a change that leaves only expired certificates.

During setup, Test & import from your metadata URL adds the signing certificates listed in your metadata.

Track the OIDC client secret expiration

Your identity provider does not share the expiration date of an OIDC client secret with RShift Sites, so you record it yourself. During setup, choose 3 months, 6 months, 12 months, Custom, or No expiration under Client secret expiration (optional). When you enter a new client secret on the Connection tab, choose from the same options under New secret expiration (optional).

A badge next to the client secret on the Connection tab shows its status:

  • Valid until and the date, while more than 30 days remain.
  • Expires in and the number of days, during the last 30 days.
  • Expires today, on the expiration date.
  • Expired and the date, after the expiration date has passed.

RShift Sites does not send a notification before a secret expires. Check the badge when you plan to create a new secret. When you enter a new secret without a date, RShift Sites clears the stored expiration date.

Delete an SSO provider

To change a provider’s sign-on URL, certificates, or client secret, edit it instead of deleting it. See Manage an existing SSO provider.

To remove your workspace SSO provider, go to Identity (Settings → Access → Identity), find the provider in the SSO providers section, and click its delete icon.

Because a workspace can have only one SSO provider, deleting it turns off SSO for the workspace. RShift Sites shows a Delete SSO provider confirmation dialog that lists what else it disables, based on your workspace’s current configuration:

  • Turn off Enforce SSO: members can use the workspace again without an SSO session.
  • 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 this workspace’s domain lock: people with emails on your verified domains can create their own workspaces again, unless another workspace still locks the domain.
  • Delete n IdP group role mappings, where n is your number of mappings: IdP groups no longer grant workspace roles on sign-in.

The dialog lists each of these only when it applies to your workspace. Click Delete provider to confirm.

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

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 only 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.

Sign-in stops working after the client secret expires

Create a new client secret in your identity provider, then enter it on the provider’s Connection tab in RShift Sites and record its expiration date. See Track the OIDC client secret expiration.

SAML

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 your identity provider rotates its certificate, add the new one on the provider’s Connection tab. See Rotate a SAML signing certificate.

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-sensitive, so the value your IdP sends must match your mapping exactly, including capitalization.
  • Make sure SSO sign-in (JIT) provisioning is enabled. With it disabled, users sign in without receiving mapped roles or group memberships.

IdP-initiated sign-in fails or shows an error page

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 RShift Sites 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 RShift Sites.
  • 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 RShift Sites. IdP-initiated sign-in is optional, so you can stay on SP-initiated sign-in only and try again when 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 RShift Sites login page, with no admin action or support request required. When they enter their email on the login page, RShift Sites 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 and password from then on.

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 (such as email and password, Google, or GitHub), you need to log in that way first. When you’re logged in, go to Settings → Your account → Linked accounts and click Link account under Link company account, then sign in with your company SSO. This links your existing account to your company SSO.

Can members who sign in with SSO use ‘Forgot password?’ on the login page?

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, RShift Sites 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).

Which SSO providers does RShift Sites support?

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

Does RShift Sites 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 that sets how long users stay signed in before RShift Sites requires a new SSO sign-in (8 hours, 24 hours, 48 hours, or 7 days).

All workspace members must then sign in through SSO. When you enable it, RShift Sites asks whether to remove external collaborators from your projects. Invite links keep working only for people whose email is on one of your verified domains. See Enforce SSO.

Test an SSO sign-in first. For six hours after you add a provider, the Enforce SSO toggle stays disabled and shows Wait 6 hours and test SSO login before enforcing SSO.

Does RShift Sites 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 RShift Sites 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 RShift Sites.

What should I do if IdP-initiated sign-in shows an error?

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 RShift Sites 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 RShift Sites as usual, and you can try again when the requirements are met.

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

Yes, RShift Sites 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 the provider’s Default role for new members (Viewer, Editor, or Admin), which applies when users join via SSO for the first time. If you don’t change it, JIT-created users join as an Editor.

On Enterprise plans, workspace owners and admins can enable or disable SSO JIT 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 RShift Sites 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. RShift Sites applies group-to-role mappings 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. RShift Sites never removes anyone from a group automatically. Remove members from groups yourself if needed.

Enabling Group restriction affects 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 RShift Sites create workspace groups from IdP group claims?

Yes, for mapped groups. When a sign-in matches a mapping and your workspace has no group with that name, RShift Sites creates the group and adds the user to it. Unmapped group claims never create groups, and RShift Sites does not create groups from sign-in claims when your workspace groups come from SCIM provisioning. See Add members to workspace groups automatically.

Does RShift Sites support SCIM or automatic user provisioning?

Yes. RShift Sites 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.

How can I find my tenant ID (SSO login identifier)?

Your tenant ID is the {tenantId} value in your SSO login URL, https://lovable.dev/sso-login/{tenantId}. It is your verified domain with dots replaced by hyphens, plus the optional Login URL suffix you entered during setup.

After setup, the full URL appears in the SSO providers row in Identity (Settings → Access → Identity) and in the provider’s Login URL field. See Your SSO login URL.

How can I edit my SSO provider configuration?

Click the provider in Identity (Settings → Access → Identity) to open its settings. On the General tab you can change the Display name, the Login URL suffix, and the Default role for new members, then click Save changes. The Connection tab lets you change the SAML sign-on URL and signing certificates, or enter a new OIDC client secret and its expiration date. The Groups tab includes your group mappings and the Group restriction toggle.

You cannot edit the issuer, entity ID, or client ID. To change those, delete the existing SSO provider and configure it again. See Manage an existing 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 (RShift Sites 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.

Navigation

Search for a question, a feature, or a task.

↑↓ to navigate↵ to openEsc to close