Every guide to Lovable authentication wires a login into a blank project.
This one is for the app that already has users, and the four failures that show up the week they arrive.
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.
Send us the build.
We will tell you honestly what needs fixing.
A senior engineer reads your actual code and sends back what is genuinely broken, what is fine, and what can wait.
Free, within 48 hours, and no obligation follows it.
If your app has few users, takes no payments and stores no personal data, you probably do not need us yet.
We will say so.
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