Set up enterprise-managed authentication

1. 1

   Open the Identity settings in your Lovable workspace (Workspace settings → Access → Identity).

   This is where you manage how users sign in to Lovable.

2. 2

   In the 'Enterprise-managed authentication' section, click 'Set up'.

   This starts the process of connecting Lovable to your company's sign-in system.

3. 3

   Choose your existing Okta SSO provider from the list and click 'Continue'.

   You are telling Lovable which sign-in system to use for your team.

4. 4

   On the 'Configure EMA' screen, confirm that the 'Provider' and 'Protocol' match your Okta setup.

   This ensures Lovable is looking at the correct sign-in system.

5. 5

   If using OIDC, review the 'Assertion issuer' value; if using SAML, enter the 'Assertion issuer' provided by Okta (e.g., 'https://example.okta.com').

   This helps Lovable verify that the sign-in requests are truly coming from your Okta system.

6. 6

   Copy the 'Audience' value ('https://lovable.dev/oauth') and the 'MCP resource' value ('https://mcp.lovable.dev') from Lovable.

   These values are needed to configure Okta and Claude to recognize Lovable.

7. 7

   Leave the 'Advanced settings → IdP tenant' field empty.

   This field is not needed for a standard Okta setup.

8. 8

   Click 'Review setup', then 'Enable team access' to save the Lovable settings.

   This completes the Lovable side of the setup, allowing it to accept sign-in requests from Okta.

9. 9

   In Okta, enable 'Cross App Access' (XAA) for your existing Lovable SSO app and connect Claude's agent to it, following Okta's XAA setup guide.

   This allows Claude to ask Okta for proof of a team member's identity to access Lovable.

10. 10

    In Claude, open the Lovable connector's 'Configuration' tab, set up 'Managed authorization', choose who gets access, select permissions (e.g., 'workspaces:read', 'projects:read'), and use 'Run test'.

    This tells Claude how to use the Okta connection to access Lovable on behalf of your team members and verifies the connection.

11. 11

    As a test member who signs into Claude through Okta and has no existing personal Lovable connection in Claude, ask Claude to 'Use Lovable to list the projects in our [workspace name] workspace'.

    This verifies that the enterprise-managed authentication works correctly and Claude can access Lovable without a separate sign-in.

Hey Lovable, I'm setting up enterprise-managed authentication for my team using Okta and Claude. I've enabled it in Lovable and copied the Audience ('https://lovable.dev/oauth') and MCP resource ('https://mcp.lovable.dev') values. Can you confirm the next steps for configuring Okta and Claude, specifically enabling Cross App Access in Okta for the Lovable SSO app and setting up Managed authorization in Claude with the correct permissions like 'workspaces:read' and 'projects:read'? Also, what's the best way to test this with a team member?

Okta single sign-on (SSO)

A system that lets you use one set of login details (like your company email and password) to access many different applications, including Lovable and Claude.

Enterprise-managed authentication

A way for company administrators to control who can use Lovable through Claude, using the company's existing sign-in system (like Okta), so individual users don't need to sign in separately to Lovable.

Lovable MCP server

The main computer system that Lovable uses to manage projects and tools. Claude talks to this server to do work in Lovable.

Cross App Access (XAA)

A feature in Okta that allows one application (like Claude) to securely request access to another application (like Lovable) on behalf of a user, without the user having to sign in again.

Identity assertion

A digital message from Okta that proves a user's identity and confirms they are allowed to access Lovable through Claude. It's like a verified digital ID card.

OIDC / SAML

These are technical standards (protocols) that define how different systems talk to each other to handle user logins and identity verification. Okta can use either of these.

Assertion issuer

The specific web address (URL) that Okta uses to send out identity assertions. Lovable uses this address to confirm that the identity message is legitimate.

Audience

A specific identifier that tells Okta which application (in this case, Lovable) is the intended recipient of an identity assertion. It ensures the message goes to the right place.

MCP resource

A specific identifier for the Lovable system that Claude wants to access. It helps Okta understand which part of Lovable is being requested.

Scopes

Permissions that define what actions an application (like Claude) is allowed to perform in another system (like Lovable). For example, 'read workspaces' or 'edit projects'.

• Do not delete or replace a working Okta SSO app to expose XAA controls, as this can disrupt sign-ins and provisioning. Contact Lovable support if your app lacks XAA controls.
• Enterprise-managed authentication does not create Lovable accounts, link existing accounts by email, or add workspace members. Members must already have a Lovable account linked via SSO.
• If your Okta setup doesn't include sign-in time in the identity assertion, Claude can remain connected beyond Lovable's session duration while Okta continues to authorize access. Control this through Okta's policies, Claude's settings, and Lovable's permissions.
• Disabling managed authentication stops new access tokens, but existing access may continue for up to 15 minutes while old tokens expire. It does not revoke self-authorized connections.
• A matching email address is not enough for a member to use Lovable tools; they must have a Lovable account linked to the SSO provider and belong to the intended workspace.
• If Claude still asks members to sign in individually, check the member's assigned role and run Claude's connection test. Claude might fall back to individual sign-in if managed authorization fails.
• Do not enter a made-up 'IdP tenant' to bypass an 'active connection' conflict; it must match the identity assertion.