Skip to main content
Your app’s built-in backend 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. Unless you name the sign-in methods you want, Lovable sets up email and password sign-in, Google sign-in, and Sign in with Lovable. For example, tell Lovable:
The Users view lets you manage the people who sign up and configure how they sign in. To open it, go to More → 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.
Add user creates one account at a time. It does not accept an existing user ID or a password hash, the scrambled form in which another tool stores a password. To move an app and its users from another tool, such as Replit or Bolt, import the project. When you add the users export, as described in Add your existing data, imported users keep their profiles and data. Their passwords do not carry over, so they verify their email and choose a new password the next time they sign in. 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 can no longer sign in, and the action cannot be undone. If the user is signed in when you delete them, they can keep using your app for the short time until their current access token expires. See How users stay signed in.

Authentication settings

Click 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 the project 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.
On Business and Enterprise workspaces, admins can block sign-in methods for all projects in the workspace with the App login methods setting (Workspace settings → Security → Privacy & security → Publishing → 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.
Building an internal tool for your own workspace members? Apps can recognize the logged-in workspace member with no login page at all. See Reuse Lovable workspace identity.
Each sign-in method has its own page with full configuration details:
  • Email: the default method, with settings for confirmation, password rules, one-time codes, and sending limits.
  • Phone: SMS one-time codes through your own SMS provider (Twilio, Twilio Verify, TextLocal, Vonage, or MessageBird).
  • Google: managed by Lovable with no setup, or your own Google Cloud OAuth credentials.
  • Apple: managed by Lovable, or your own Apple Developer credentials.
  • Microsoft: managed by Lovable with no setup, or your own Azure app registration.
  • Lovable: sign-in with a Lovable account, managed by Lovable with no setup.
  • SAML SSO: sign-in through a SAML 2.0 identity provider such as Okta or Microsoft Entra ID.
  • OIDC: sign-in through your own OpenID Connect provider such as Auth0, Okta, Microsoft Entra ID, or Keycloak.

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 the project 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.
For apps on the built-in backend, Lovable keeps both up to date for you. When you publish, Lovable sets the Site URL to your app’s published address, unless the Site URL is already on your own domain. When you connect a custom domain, Lovable adds it to the redirect URLs. When Lovable sets up your app’s OAuth server, it sets the Site URL to your app’s main address, even when you set the Site URL yourself. Apps that use your own Supabase project are different. Lovable adds its own addresses to that project’s redirect URLs, but the Site URL and any address Lovable does not serve are yours to set in that project’s auth settings. To sign people in on an address Lovable does not serve, add the address under Redirect URLs yourself. Examples are a web app hosted outside Lovable that uses your project’s backend, a local copy of your app, or a mobile app scheme:
  • End a web address in /**, so that every path on it matches, for example https://app.yourdomain.com/**.
  • Use a domain you own. Each time Lovable updates the list, it removes other addresses on Lovable domains, such as another lovable.app address.
  • To test on your computer, open your app at an address such as http://127.0.0.1:5173 and add http://127.0.0.1:5173/**. Lovable rejects localhost addresses.
Managed Google, Apple, Microsoft, and Lovable sign-in also work for these addresses. Sign-in starts at an address Lovable serves, such as your app’s lovable.app address, and then returns to the address you added. If sign-in works in preview but breaks on your published app or custom domain, these URLs are usually the reason. Ask Lovable in the project chat to update them for your domain. If your app uses Google sign-in with your own Google OAuth credentials, the new domain also needs a redirect URI in Google Cloud Console. See Managing Google authentication.

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 emails under More → Emails. See Custom emails.

How users stay signed in

A session is the time a person stays signed in to your app, from sign-in to sign-out. Your users usually stay signed in between visits until they sign out or you delete their account. Lovable does not offer settings to limit how long a session lasts or to sign people out after a period of inactivity. When a person signs in, Lovable gives them two tokens that keep their session going:
  • Access token: your app sends the access token with each request to your app’s backend to show who the person is. The access token expires after a short time, and Lovable does not offer a setting to change how long it lasts.
  • Refresh token: your app uses the refresh token to get a new access token, so the person does not have to sign in again.
Your app stores both tokens on the person’s device and renews the access token automatically. When a person signs out, or when you delete their account, Lovable ends their session, so their refresh token no longer works. An access token that Lovable issued before the sign-out or deletion can keep working until it expires. You can block a sensitive action, such as showing payment details, for a person immediately after they sign out or you delete their account. Ask Lovable in the project chat to add a session check before the action. With a session check, your app asks its backend whether the person’s session is still active, and stops the action if the session has ended.

Signing keys

A signing key is the secret that your app’s built-in backend uses to sign each access token. The signature shows that your backend created the token and that nobody changed it. Your app checks the signature before it trusts a token, so nobody can pose as one of your users with a made-up token. Your project’s signing key is usually one of two kinds, and your app’s own sign-in works with both:
  • Shared secret (HS256): your backend signs and checks tokens with one secret. Lovable keeps the secret private, so a server outside your app has to ask your backend to check a token.
  • Key pair (ES256): your backend signs tokens with a private key and publishes the matching public key. Any server, such as your own server on another host, can use the public key to check your app’s tokens, but not to create them.
When you publish your app as an MCP server that requires sign-in, people sign in to it from an AI assistant, such as ChatGPT or Claude. Sign-in through an MCP server needs a key pair. If your project uses a shared secret, Lovable switches your project’s signing key to a key pair when you publish the MCP server. You can also ask Lovable in the project chat to migrate your project’s signing keys at any time. For example, ask for a migration when connecting your app to an AI assistant fails with an error about HS256. Lovable asks you to confirm before it migrates the keys. After Lovable switches your project to a key pair, tokens signed with the old shared secret keep working until they expire. Your users do not need to do anything. Your app gets tokens signed with the key pair the next time it renews each person’s access token.

Let other apps connect on behalf of your users

Your app’s built-in backend can act as an OAuth server, so other apps can connect to your app on behalf of your users. An AI assistant, such as ChatGPT or Claude, that connects to your app through an agent integration works this way. The person signs in to your app and approves the assistant’s access on a consent page. The assistant then acts as that person. Lovable sets up the OAuth server when you publish your app as an MCP server that requires sign-in. You can also ask Lovable in the project chat to set it up, or to check the setup when an app cannot connect. Lovable builds a consent page in your app, where people approve another app’s access. When Lovable sets up the OAuth server, it also:
  • lets other apps register themselves by default: each app gets its own ID from your app’s OAuth server, so you do not need to add each app yourself. People still approve each app on the consent page the first time it connects.
  • sets your app’s Site URL to its main address: your primary custom domain, your published lovable.app address, or the preview address if the app is not published yet
The OAuth server needs a key pair to sign the tokens it issues. If your project uses a shared secret, Lovable switches it to a key pair when you publish your app as an MCP server that requires sign-in. If you set up the OAuth server another way, ask Lovable in the project chat to migrate your project’s signing keys. See Signing keys.

FAQ

No. Google, Apple, and Microsoft 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.
Yes. On Business and Enterprise workspaces, admins can block sign-in methods for every project in the workspace with the App login methods setting (Workspace settings → Security → Privacy & security → Publishing → App login methods). Blocked methods are locked: project owners can turn them off but cannot turn them back on.
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.
The published URL or custom domain is missing from your project’s redirect URLs. For apps on the built-in backend, Lovable adds these addresses automatically when you publish and when you connect a custom domain. If sign-in still fails, or your app uses your own Supabase project, ask Lovable in the project chat to add your domain to the auth redirect URLs, or add it under More → Users → Settings → Advanced → Redirect URLs. If your app uses Google sign-in with your own Google OAuth credentials, also add the new domain’s redirect URL in Google Cloud Console and select it in Lovable. See Managing Google authentication.
Yes. Open More → Users → Settings → Advanced → Redirect URLs. Alongside your own entries, the list shows what Lovable adds for you: your preview and published addresses, your connected custom domains, and your phone app’s scheme.See Site URL and redirect URLs for the addresses you add yourself, and the ones Lovable removes again. The list shows your saved settings, so when a redirect fails even though it matches, ask support to compare it with the live configuration.
No. Lovable has no setting for how long an access token lasts, how long a session lasts, or how long someone can stay idle before your app signs them out. See How users stay signed in.
Either a shared secret (HS256) or a key pair (ES256), depending on your project. Your app’s own sign-in works with both, and tokens signed with an older key keep working until they expire. See Signing keys.To find out which one your project uses now, ask Lovable in the project chat. A key in your app’s public key list is not necessarily the one that signs new tokens.
Yes for an address outside Lovable, as long as you add it to Redirect URLs and keep the built-in backend connected. Connected custom domains work too. See Site URL and redirect URLs.A provider’s own native sign-in is a different setup, because it uses a separate client ID for the app. See native sign-in with Google and native Sign in with Apple.
You can change one authentication rate limit yourself: Rate limit for sending emails caps every authentication email your project sends in an hour, confirmations, password resets, magic links, invites, email changes, and re-authentication together. See Sending limits.Before a launch or another burst of sign-ups, contact support to review the rest of your project’s limits.
An access token can. Signing out and deleting an account both end the session, so the person cannot renew their access token, but a token Lovable already issued works until it expires. See How users stay signed in.To cut access off at once, ask Lovable in the project chat to add a session check before the sensitive action. After you delete an account, clear the app’s stored session on the device.
Not with Add user, which takes an email address and a new password and nothing else. For an app that is not in Lovable yet, importing the project moves its users instead. See Manage users.Do not send invitations as a quiet way to import people, because each one emails them.