Skip to main content
When you build an internal tool in Lovable, the people who use it are usually your own teammates, and they already sign in to Lovable every day. Workspace identity reuse lets your app treat that existing sign-in as its login: the app knows who is visiting (their name, email, and Lovable user ID) without showing a login page or asking anyone to create another account. It works no matter how someone signs in to Lovable: workspace SSO, Google, or email. You do not need workspace SSO configured. The feature is available on Business and Enterprise plans and is rolling out gradually, so it may not be available for every project yet.
This page documents Lovable workspace identity reuse for apps you build in Lovable.Looking for SSO for your team’s access to Lovable itself? See Set up workspace single sign-on (SSO). Looking for SAML SSO for external users of a Cloud app? See Add SAML single sign-on to Lovable Cloud apps.

​
Why use Lovable workspace identity reuse

Identity reuse fits when everyone who uses your app is already in your Lovable workspace. Without it, you would need to build and maintain a second login system, and your teammates would sign in twice: once to Lovable, and once to your app. With it, the app already knows the current user’s name, email, and user ID. This is most useful for internal tools, employee portals, admin dashboards, approvals apps, reporting tools, and workspace-only workflows. For customer-facing apps, public signup flows, or apps where users do not have Lovable accounts, use traditional app authentication instead.

​
Common use cases and example apps

If you ask Lovable to “add login” in an eligible internal app, clarify that you want to reuse the signed-in Lovable user. This helps Lovable choose the workspace-member identity model instead of adding email, Google, or SAML sign-in for external app users.

​
Prerequisites

To use Lovable workspace identity reuse, you need:
  • A Business or Enterprise workspace.
  • A newer Lovable project that uses TanStack Start. Some older projects are not eligible.
  • Lovable workspace identity reuse enabled for the workspace.
Lovable Cloud is not required to use workspace identity reuse. If your app uses Lovable Cloud, the same signed-in Lovable identity can also help with per-user data access. If you are not sure which stack your project uses, ask Lovable:
You do not need to configure workspace SSO. Workspace SSO can be useful for company access control, but this feature reuses the Lovable account identity that already exists after any supported Lovable sign-in method.
Workspace admins and owners can disable Lovable workspace identity from App login methods. To use this feature in an individual project, ask Lovable to add workspace identity reuse to the app.

​
How Lovable workspace identity reuse works

When an eligible signed-in user opens the preview or published app, Lovable creates a short-lived identity token for that project and user. Lovable’s proxy passes that identity to the app request, and the generated app helper verifies it before exposing the current user to your app code. The app can then use the signed-in Lovable user as an ambient identity. In practice, this means you can ask Lovable to show the current user’s name, filter data to the current user, or use the identity in app logic without creating an app-specific sign-in page. Lovable protects the identity boundary by stripping incoming identity headers before it adds its own signed identity token. This prevents visitors from spoofing another user by sending their own identity header.

​
What your app can read

When Lovable adds the identity helpers, your app can read:
  • The signed-in user’s Lovable user ID.
  • The user’s display name, when available.
  • The user’s email address, when available.
If a visitor does not have a valid Lovable identity for the request, the helper returns no user. Your app should handle that state with a guest message, access-denied state, or traditional authentication flow, depending on your use case.

​
How it works with Lovable Cloud

Lovable Cloud is not required for workspace identity reuse. For apps that do use Lovable Cloud, Lovable can use the signed-in Lovable identity when your app needs per-user data access. This lets Lovable Cloud-backed features recognize the current workspace member without adding a separate app sign-in flow. Use this pattern when each workspace member should only see or edit their own Cloud data. For example, an internal task tracker can show each signed-in Lovable user only the tasks assigned to them.
Do not mix Lovable workspace identity reuse with a traditional app sign-in flow unless you intentionally design a hybrid app. For most apps, choose one auth model: Lovable identity for workspace-member apps, or traditional app authentication for public and customer-facing apps.

​
Set up Lovable workspace identity reuse

Workspace identity is managed from App login methods in workspace Privacy & security settings. To use it in an individual project, ask Lovable to add workspace identity reuse to the app.
1

Open App login methods

Go to Workspace settings → Privacy & security → App login methods → Configure.
2

Find Lovable workspace identity

Look for Lovable workspace identity in the sign-in options.
3

Confirm the workspace setting

Keep Lovable workspace identity available if apps in your workspace should be able to reuse the signed-in Lovable user.If Lovable workspace identity is disabled, apps cannot use workspace identity reuse.
4

Ask Lovable to use the signed-in user

Use a prompt that describes the identity behavior you want. Lovable will make the app changes needed to use workspace identity reuse.
5

Test in preview

Open the app preview while signed in to Lovable. The app should show the current Lovable user or the access state you requested.
You can test identity reuse in preview. You do not need to publish first.

​
When to use traditional app authentication instead

Use traditional app authentication when:
  • Your app is customer-facing or public.
  • Users should create accounts inside the app.
  • Users may not have Lovable accounts.
  • You need app-specific login methods such as email/password, magic links, Google sign-in, Microsoft sign-in, or SAML SSO for Cloud app users.
  • You need external customer lifecycle management that is separate from Lovable workspace membership.
In those cases, ask Lovable to add the sign-in method you need, such as Google authentication, email sign-in, or SAML SSO for Cloud app users.

​
FAQ

No. Workspace SSO controls how your team signs in to Lovable. Workspace identity reuse lets an app you build read the Lovable user who is already signed in.
No. The reused identity is the signed-in Lovable account identity, regardless of whether the user signed in with workspace SSO, Google, email, or another supported Lovable sign-in method.
Lovable workspace identity reuse is available on Business and Enterprise plans for newer projects that use TanStack Start. Some older projects are not eligible.
No. Public visitors who are not signed in to Lovable do not receive a Lovable identity. Use traditional app authentication if public or customer users need accounts.
Only for apps where the users are workspace members already signed in to Lovable. For customer-facing apps or external users, use app authentication such as Google auth, email auth, or SAML SSO (available in Lovable Cloud). You may also use other app authentication methods for internal apps if you need app-owned user accounts, signup and login flows, Cloud Auth user management, OAuth providers, or auth logs and analytics.
The identity reuse feature itself does not create a separate billing line item. Any Lovable Cloud database, storage, hosting, or AI usage in the deployed app still follows normal credits and usage rules.

​
Troubleshooting

Confirm that your workspace is on a Business or Enterprise plan and that your project uses TanStack Start. Some older projects are not eligible. If you are not sure which stack your project uses, ask Lovable: What stack is this project on?
Open the preview while signed in to Lovable, confirm that Lovable workspace identity is allowed in App login methods, and ask Lovable to add workspace identity reuse to the app. If your app supports anonymous visits, make sure it handles the no-user state clearly.
Ask Lovable to use the signed-in Lovable user as the app identity. For example:
Ask Lovable to wire the signed-in Lovable identity into your Lovable Cloud data access. Avoid mixing this setup with a separate app sign-in flow unless you are intentionally building a hybrid auth model.