The short version
Google login started bouncing to the preview URL the day your domain went live. Sign-ups stopped getting their confirmation email. A customer wants an admin who can see their whole team, and an investor just asked whether you have two-factor. None of those is a Lovable problem, exactly. Lovable Cloud runs on Supabase Auth underneath, so every one of them is a Supabase setting the prompt box never mentioned.
Here is the short version. The app does not need rebuilding. Authentication in a Lovable app is a handful of configuration decisions plus one database policy per table, and they can be fixed in place, in an afternoon or a week depending on which ones got skipped, without logging out a single existing user. This page goes through them in the order that stops the bleeding first.
One thing before the detail. If you have under a hundred users, take no payments and hold nothing personal, read the section on who does not need to touch any of this and probably stop there. We would rather say that now than three sections in.
What does Lovable actually give you for authentication?
A real authentication system, not a mock. Lovable Cloud ships email and password, magic links, one-time codes, phone, Google, Apple, Microsoft and SAML SSO, plus an anonymous-user mode for guest flows, all configured from the Cloud tab under Users and then Auth settings. Underneath it is Supabase Auth, the same thing you would get by connecting your own Supabase project, and our Lovable Cloud vs Supabase guide covers who owns what in that arrangement.
That matters because it tells you where the settings live. When Google login breaks, it is not the React code Lovable generated. It is a URL in Supabase's auth configuration. When confirmation emails stop, it is a rate limit on Supabase's built-in mailer. When one user can see another's rows, it is a missing Row Level Security policy on a Postgres table. The generated code is usually fine. The configuration around it was set for a demo.
Three defaults deserve naming because each is right for building and wrong for launching. Auto-confirm. Lovable's own docs call it convenient while building and testing, because you can create accounts without checking an inbox. Leave it on and anyone can sign up with an address they do not own. The built-in email provider, which Supabase caps at two messages an hour. And the Site URL, which points at wherever the app lived when auth was first wired up, and that is never your production domain.
Lovable also ships two security scanners. The Basic scan lints RLS policies, reviews the schema and audits dependencies. The Deep scan adds access control review and backend endpoint protection. Run both. Then read the sentence in the same documentation that says you are responsible for ensuring the app meets the security requirements of its use case, because that sentence is why this page exists.
Why does Google login break the week you connect a custom domain?
Because Google never talks to your domain. It talks to Supabase, and Supabase sends the user wherever its Site URL says, which is still the preview address.
The flow has three parties and two of them keep a list of allowed addresses. Your app sends the user to Google. Google sends them back to Supabase's callback URL, which has to appear in Google Cloud's authorised redirect URIs. Supabase then sends the user on to your app, at the Site URL by default or at whatever redirectTo you passed, and that address has to be on Supabase's redirect allow-list. Connect a custom domain and neither list has heard of it. The user signs in with Google successfully, lands on the old preview URL, and tells you login is broken.
Lovable offers two ways to run Google sign-in and they fail differently. Managed by Lovable means Lovable owns the OAuth client and the redirect handling, with no Google Cloud console at all, at the cost of being limited to email and basic profile scopes and to apps on Lovable Cloud. Your own credentials means you own the consent screen and any scope you need. Lovable's docs are blunt about the most common failure there: the redirect URIs you selected in Lovable do not exactly match the ones in Google Cloud. Scheme, path, trailing slash. All of it has to match.
The checklist to run before you flip the domain, not after. Set Site URL to the production domain with the exact path. Add the production domain to the redirect allow-list and remove localhost and the preview URL. If you run your own credentials, add Supabase's callback to Google Cloud's authorised redirect URIs. And set a custom auth domain, because Supabase's guide says that without one users see your Supabase project id on the consent screen, which makes the app more susceptible to successful phishing attempts. That is not a sentence you want to explain to a customer.
Wildcards exist on the allow-list and they are useful for preview branches. In production, use the exact URL. A pattern that matches your staging subdomain also matches a subdomain somebody else registers.
Why did sign-ups stop confirming?
Because Supabase's built-in email provider sends 2 emails an hour, and that limit can only be raised by configuring your own SMTP.
This one arrives on launch day like clockwork. Ten people sign up in the first hour, two of them get a confirmation email, eight write to you. Lovable's docs describe the symptom exactly: if many sign-ups happen at once your project may have hit its hourly email rate limit, and the fix is custom email sending through your own domain. Supabase publishes the rest of the table. 30 one-time passwords an hour across the whole project. A 60-second window per user before a second magic link or code goes out. 360 verification requests an hour, 1,800 token refreshes, 30 anonymous sign-ins, 15 MFA challenge and verify calls.
The tempting fix is to switch confirmation off. Do not. Lovable's own docs say it plainly: without confirmation, anyone can sign up with an address they do not own. The right fix is a transactional email provider on your domain, ten minutes of DNS, and the built-in limit stops applying. While you are there, read what the templates say and where their links point, because confirmation and password-reset links go to the Site URL, the same setting from the previous section.
Two smaller things in the same area. Password reset in Supabase deliberately does not reveal whether an account exists, so a user who typed the wrong email sees the same message as one who typed the right one. Say so in the interface or support will hear about it. And the leaked-password check against Have I Been Pwned, which Lovable exposes as a setting, is a Pro plan feature on Supabase's side, so if you moved off Lovable Cloud onto a free Supabase project it is silently not there.
Who does not need to touch any of this?
More people than the security vendors would like.
If you have fewer than a hundred users, take no payments, store nothing you would call personal, and nobody outside your own company logs in, you do not need a development partner and you do not need Auth0. You need three switches. Confirm email is on. Site URL is your real domain. Row Level Security is enabled on every table that holds user data, which our vibe coding security guide walks through with the SQL. Do those, run Lovable's Deep scan, and go back to building the product.
If the app is internal, same answer with one addition. Turn on Google or Microsoft sign-in restricted to your company domain and you have solved onboarding and offboarding with one setting.
Come back when one of five things happens. Someone pays you. You store health, financial or identity data. A customer asks for their own admin. A customer asks for SSO. Or a second business unit needs its own users on the same app. Those are the triggers for the rest of this page, and until one fires the rest is premature.
How do you add roles and an admin without a rebuild?
Store the role in a table, put it into the token with an auth hook, and check it in the database policy. Never store it anywhere the user can edit.
The first version usually goes wrong in one of two ways: a role column on a profile row the user can update, or a role in user metadata. Supabase's RLS documentation is explicit that raw_user_meta_data is user-modifiable and unsuitable for authorisation, while raw_app_meta_data cannot be changed by the user. An admin flag a user can set on themselves is not a role. It is a suggestion.
The pattern Supabase documents is short. A user_roles table keyed on the user id. A Custom Access Token Auth Hook, which is a Postgres function that runs before every token is issued and adds a user_role claim to the JWT. Then policies that read the claim, so a team's admin view is visible only to sessions whose token says they belong there. One trap in the same docs: the hook changes the access token but not the auth response object, so the client has to decode the JWT to learn the role. A frontend that reads the role from the session object will treat everyone as a viewer and you will spend a day wondering why.
This is also where multi-tenancy starts, and it is not a rebuild either. A tenant id on every table, a membership table joining users to tenants with a role, and a policy that says a row is visible when a membership exists for the current user and this row's tenant. Lovable can generate the tables. What it cannot do is test the policy from a second account, which is the only test that counts. Sign in as a user in tenant B and try to read tenant A's rows by changing the id in the request. If it works, you are not done.
Frontend role checks stay, for the interface. They hide the button. The policy is what stops the request.
Do your users need two-factor, and how is that different from your own Lovable account?
They are two different systems. Two-factor on your Lovable account protects your editor seat and your deploy button. Multi-factor for your app's users is a Supabase Auth feature you enrol them in yourself, and about half the search results for the phrase confuse the two.
Lovable's account 2FA lives under your own login and works whichever way you sign in. It protects the thing that can redeploy your app. Turn it on today. It takes a minute and it is the cheapest security win on this page.
Your users are separate. Supabase Auth offers two factor types, an authenticator app using time-based codes and phone messaging using a code Supabase generates. The API has three parts: enrol a factor, challenge it, verify the code. After a normal login the token carries an assurance level of aal1. After a second factor it carries aal2. That claim is what makes the feature worth having, because you can write a restrictive policy on a sensitive table that reads (select auth.jwt()->>'aal') = 'aal2', and the payout table or the medical record simply does not exist for a session that only did a password.
Who needs it: anyone handling money, health or identity, anyone whose customers are companies with a security questionnaire, and anyone who has already had one account taken over. Who does not: a consumer app where the worst case is a lost to-do list, where a second factor costs sign-ups for nothing. The rate limit is real as well, 15 challenge and verify requests an hour, so a login screen that retries in a loop will lock people out of the very thing meant to protect them.
How long should a session last, and what happens to the people already logged in?
One hour for the access token, which is Supabase's default and the right answer for most apps. And nobody gets logged out when you change it, because sessions are only enforced at the next refresh.
This is the section for the founder afraid that hardening means every existing user is signed out on a Tuesday morning. It does not. Supabase's model is a short-lived access token, one hour by default, and a refresh token that never expires on its own but can be used exactly once, with a 10-second reuse window so a flaky network does not sign people out. Tighten the settings and Supabase's docs are explicit that sessions are not proactively destroyed. The new rule applies the next time each session refreshes, so the real lifetime is the timeout plus one token expiry. Users notice nothing.
The controls beyond the default are Pro plan features on Supabase's side. A time-box that ends a session after a fixed duration regardless of activity. An inactivity timeout. And single session per user, which keeps the most recent sign-in and closes the rest. That last one is the answer to shared logins on a paid plan, and to the support ticket where a former employee is still signed in on a laptop nobody can find.
The rule of thumb in our production checklist for Lovable apps, a one-hour access token and a refresh window measured in days, still stands. What that checklist could not fit is the mechanism, and the mechanism is what tells you the change is safe to make on a live app.
Do you need Auth0, WorkOS or Clerk, or is Supabase Auth enough?
Enough, for most Lovable apps. The pages telling you otherwise are mostly written by the vendors.
We read the search results for this question while planning this page. There were no Lovable-specific answers at all, and the general ones came from WorkOS, from Auth0 integration partners, or from people selling an alternative to both. That is not a reason to distrust the products. It is a reason to notice who is answering.
The honest line is this. Supabase Auth covers email, social login, magic links, phone, MFA, roles through the hook above, and enforcement in the database through RLS. That is everything on this page. The moment to reach for WorkOS or Auth0 is enterprise SSO: a customer who needs SAML against their own identity provider, SCIM provisioning so their IT team can add and remove seats, or audit logs their compliance team will ask for by name. Lovable Cloud lists SAML SSO among its sign-in methods, so even that case may already be covered on the built-in path, and it is worth testing before you add a vendor, a second user store and another bill to reconcile.
Clerk is a different trade: a very good pre-built interface for auth in exchange for holding your users in Clerk. If your users already live in Supabase, moving them is a migration with password resets attached. That is a change you make once, for a reason, not because a tutorial did.
Adding a vendor does not remove the RLS work. Whoever issues the token, the database still has to check it.
When it is worth handing this to someone
The moment someone else's money or data sits behind the login.
If the disqualifier section described you, do the three switches and go. If one of the five triggers has fired, the work on this page is a week of careful configuration and testing for someone who has done it before, and a month of guesswork for someone who has not, because the failures are silent. A policy that allows too much does not throw an error. A hook that forgot a claim makes everyone a viewer, quietly. A redirect allow-list wildcard that is too wide never complains.
That is the work we do at Geminate Solutions. We take apps built in Lovable, Bolt, v0 and Replit and get them to the point where real customers can be trusted with them, and we do not sell rebuilds. Your Lovable app stays your Lovable app. We have shipped 50+ products, run an EdTech platform at 250,000+ daily users and an exam system absorbing 10 million requests a minute, and hold Top Rated Plus on Upwork at 4.9. You own the code from the first commit. Our AI builder to production service lays out how an engagement runs. If it is the backend rather than the login that is creaking, the Lovable backend solutions guide is the sibling to this one.
The first step is a written review of what your auth configuration will and will not hold: the two URL lists, the email path, the session settings, the roles, and a second-account test against every table. We send it back within 48 hours and it stays yours whether or not we ever talk again.
Frequently Asked Questions
Can a Lovable app use magic link login instead of passwords?
Yes. Lovable Cloud supports magic links and one-time codes alongside passwords, all through Supabase Auth. The sending limits still apply: the built-in mailer sends 2 emails an hour and each user can request one link or code per 60 seconds, so configure your own sending domain before you rely on it with real users.
Does hardening authentication log out my existing users?
No. Supabase enforces session settings at the next token refresh rather than destroying sessions, so a tighter timeout takes effect gradually and silently. Changing the Site URL, the redirect allow-list, the email provider or the MFA settings does not end anyone's session either.
Does Row Level Security replace authentication?
No. Authentication establishes who the user is. Row Level Security decides which rows that user may read or write. Without it a logged-in user can read every row through the public key, because a table in an exposed schema with no policy is open to any role with a grant. You need both.
Can a Lovable app be multi-tenant without a rebuild?
Yes. Add a tenant id to each table, a membership table linking users to tenants with a role, and a policy that checks membership for the current user on every read and write. Then test from a second account in a second tenant, which is the only test that proves it.
Is two-factor on my Lovable account the same as MFA for my users?
No. Two-factor on your Lovable account protects your editor and deploy access. MFA for your app's users is a Supabase Auth feature with authenticator app and phone factors, enrolled per user, which raises the session's assurance level to aal2 so sensitive tables can require it.
