> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lovable.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Users and authentication

> Manage your app's users and configure how they sign in: email, phone, Google, Apple, and SAML SSO, all part of the built-in backend (Cloud).

Your app's built-in backend (Cloud) includes authentication. Ask Lovable to add login, and it generates the signup and login pages, wires them to your backend, and protects user data with row level security. For example, tell Lovable:

```text wrap theme={null}
Add login to the app. Require login before accessing the CRM dashboard. Also, add a 'Sign in with Google' button so users can log in with their Google accounts.
```

The **Users** view lets you manage the people who sign up and configure how they sign in. To open it, go to **Cloud tab → Users**.

## Manage users

The Users view shows a **Signups** chart of new users over the last 7, 30, or 90 days, and a searchable list of every user in your app.

To add users yourself, click **Add user**:

* **Send invitation**: enter an email address and Lovable sends the person an invite email to join your app.
* **Create new user**: enter an email address and password to create the account directly. Users created this way are automatically confirmed.

Click a user to open their details, including their user ID, sign-up and last sign-in timestamps, and which login methods they use. The **Raw JSON** tab shows the full user record.

To remove a user, open their details and choose **Delete user**. The user loses access to your app, and the action cannot be undone.

## Authentication settings

Click **Auth settings** in the Users view to configure how users sign in. The **Sign in methods** list shows each available method with an **Enabled** or **Disabled** badge.

You can change these settings directly, or ask Lovable in chat. When you enable a sign-in method, Lovable can also update your app's login page, for example by adding the matching sign-in button.

<Note>
  On Business and Enterprise workspaces, admins can block sign-in methods for all projects in the workspace with the [App login methods](/features/privacy-and-security-settings#app-login-methods) setting (**Settings → Security → Privacy & security → App login methods**). The policy controls what you can change in your project's auth settings: you cannot enable a method the policy blocks, and a blocked method that was already enabled can still be disabled, but not enabled again. Locked methods show a **Workspace policy** badge.
</Note>

<Tip>
  Building an internal tool for your own workspace members? Apps can recognize the signed-in workspace member with no login page at all. See [Reuse Lovable workspace identity](/features/lovable-workspace-identity-reuse).
</Tip>

Each sign-in method has its own page with full configuration details:

* [Email](/features/email-auth): the default method, with settings for confirmation, password rules, one-time codes, and sending limits.
* [Phone](/features/phone-auth): SMS one-time codes through your own SMS provider (Twilio, Twilio Verify, TextLocal, Vonage, or MessageBird).
* [Google](/features/google-auth): managed by Lovable with no setup, or your own Google Cloud OAuth credentials.
* [Apple](/features/apple-auth): managed by Lovable, or your own Apple Developer credentials.
* [SAML SSO](/features/saml-sso): sign-in through a SAML 2.0 identity provider such as Okta or Microsoft Entra ID.

## Sign-up controls

Two settings on the main auth settings form control who can join your app:

* **Disable sign-up**: prevent new users from signing up. Existing users can still sign in, and you can still add users with **Add user**.
* **Enable anonymous users**: let visitors use your app without creating an account. Ask Lovable in chat to build flows that use anonymous sessions, such as guest checkouts.

## Site URL and redirect URLs

Under **Advanced** in the auth settings:

* **Site URL**: the default URL users are redirected to after authentication when no redirect URL is specified.
* **Redirect URLs**: up to 50 URLs that auth providers are permitted to redirect to after authentication. Custom schemes (for example, `myapp://callback`) are supported for mobile apps.

If sign-in works in preview but breaks on your published app or custom domain, these URLs are usually the reason. Ask Lovable in chat to update them for your domain.

## Auth emails

Authentication flows send emails for signup confirmation, password resets, invites, magic links, email changes, and re-authentication. By default they come from a generic sender. To send them from your own domain with custom branding, set up the **Emails** section of the Cloud tab. See [Custom emails](/features/custom-emails).

## FAQ

<AccordionGroup>
  <Accordion title="Do I need my own Google or Apple developer account for social sign-in?">
    No. Google and Apple sign-in work in Managed by Lovable mode, where Lovable handles the OAuth configuration and security updates. You only need your own credentials if you want the consent screen to show your own branding and verified domain.
  </Accordion>

  <Accordion title="Can workspace admins control which sign-in methods projects use?">
    Yes. On Business and Enterprise workspaces, admins can block sign-in methods for every project in the workspace with the [App login methods](/features/privacy-and-security-settings#app-login-methods) setting (**Settings → Security → Privacy & security → App login methods**). Blocked methods are locked: project owners can turn them off but cannot turn them back on.
  </Accordion>

  <Accordion title="Are my app's users copied when I remix a project?">
    No. Remixing copies the structure of backend data, such as tables and auth configuration, but not the data itself. The remixed project starts with no users.
  </Accordion>

  <Accordion title="Why does sign-in fail on my published app but work in preview?">
    The published URL or custom domain is probably missing from your project's redirect URLs. Ask Lovable in chat to add your domain to the auth redirect URLs, or add it under **Auth settings → Advanced → Redirect URLs**.
  </Accordion>
</AccordionGroup>
