Lovable Login Not Working? Fix Google, Email & OAuth Auth

Why is login not working in my Lovable app?

Because Supabase auth is misconfigured somewhere between the sign-in request and the redirect back to your app. The credentials and Supabase keys are usually fine. What breaks is one of four config layers: the OAuth redirect URL is not on the allow list, confirmation or reset emails are not being sent, the Site URL is wrong, or the session is not persisted after sign-in. Match your symptom in the table below.

The fastest way to narrow it down is to separate the two big families of failure. If the sign-in flow itself never completes — Google returns you to the login page, or the magic link or reset link dead-ends — you have a redirect URL problem. If sign-in works but no email ever arrives, you have an email-delivery problem. Both live in the Supabase dashboard under Authentication, not in the React code Lovable generates, which is why re-prompting the AI to 'fix login' rarely helps.

One symptom is deliberately excluded here: signing in successfully and then bouncing straight back to the login page on refresh. That is a session-persistence loop with its own diagnosis, and we cover it in a dedicated guide linked below.

Related: fix the Lovable login loop where you bounce back to /login · diagnose broader Lovable Supabase errors

Why does Google (OAuth) login not work in my Lovable app?

Because the URL Supabase tries to send the user back to after Google approves them is not on your redirect allow list, so Supabase refuses it. The Supabase docs are explicit: the redirectTo URL you pass to signInWithOAuth must be added to your redirect allow list. If your production domain, preview domain, or localhost is missing, Google authenticates the user and then the round trip is rejected — you land back on login, still signed out.

There are two separate URL settings that both have to be right, and mixing them up is the most common reason Google login silently fails. The first is the OAuth callback URL that Google itself posts back to — that belongs in the Google Cloud console and must match the callback URL Supabase shows on the Google provider page (it has the form https://<project-ref>.supabase.co/auth/v1/callback). The second is the redirectTo in your own code, which is where Supabase sends the user after it finishes the exchange — that must appear in the Supabase Redirect URLs allow list.

If Google login works locally but breaks on your live domain, the callback URL is fine and the redirectTo allow list is the problem: your production URL was never added. Fix the allow list, redeploy, and test in a clean incognito window.

1. In the Supabase dashboard, open Authentication > Providers > Google and copy the exact callback URL shown there (of the form https://<project-ref>.supabase.co/auth/v1/callback).
2. In the Google Cloud console, open your OAuth client and paste that callback URL into Authorized redirect URIs — it must match character for character.
3. Copy the Google Client ID and Client Secret back into the Supabase Google provider page and save.
4. In your code, make sure any redirectTo you pass to signInWithOAuth is a URL you have also added to the Supabase Redirect URLs allow list.
5. Add your production URL, your Lovable preview URL, and your local dev URL (for example http://localhost:3000) to the Redirect URLs list.
6. Redeploy and test Google login in an incognito window so no stale session hides the result.

Related: Login with Google (Supabase docs)

Why aren't my Lovable confirmation emails sending?

Because Lovable apps ship on Supabase's built-in email service, which is intended only for testing. Per the Supabase docs it is rate-limited to roughly two messages per hour and, without a custom SMTP server, it will refuse to deliver messages to any address that is not part of your project's team. So your own test email may work while every real user's confirmation email silently fails.

This is the trap that makes email-confirmation flows look fine in development and break the instant a stranger signs up. You test with your own email — which is on the project team — and it arrives, so you ship. Real users, whose addresses are not on the team, get nothing, and they hit an 'Email not confirmed' wall the first time they try to log in.

The fix is to connect a custom SMTP provider (Resend, Postmark, Amazon SES, SendGrid, and similar all work). Once custom SMTP is configured, Supabase will send to all addresses. The docs note a low initial rate limit of 30 messages per hour on custom SMTP, which is adjustable — plenty to unblock real signups while you tune it.

1. Create an account with an email provider (Resend, Postmark, SendGrid, Amazon SES, or similar) and verify your sending domain.
2. In the Supabase dashboard, open Authentication and enable custom SMTP under the email/SMTP settings.
3. Enter the host, port, username, password, and sender address from your provider.
4. Save, then trigger a signup with a fresh non-team email address and confirm the message arrives.

Related: Configure a custom SMTP server (Supabase docs)

How do I fix a broken password reset in Lovable?

Because a Supabase password reset is a two-step flow and Lovable often wires up only the first half. resetPasswordForEmail sends an email whose link carries a recovery session; the redirectTo you pass must point at a change-password page that is on your redirect allow list. That page then has to collect the new password and call updateUser. If the redirect URL is missing or the second step is absent, the link dead-ends.

A reset that emails a link which lands on your homepage, or throws an error, almost always means the redirectTo target is not allow-listed or there is no page wired to complete the reset. The email is only a delivery mechanism — the actual password change happens in your app after the recovery session loads.

Note that resetPasswordForEmail depends on the same email delivery covered above. If confirmation emails are not sending because of the default SMTP limits, reset emails will not send either — fix custom SMTP first, then the reset flow.

1. Confirm your change-password route (for example https://yourapp.com/reset-password) is added to the Supabase Redirect URLs allow list.
2. Call supabase.auth.resetPasswordForEmail(email, { redirectTo: 'https://yourapp.com/reset-password' }) using that exact URL.
3. On the reset-password page, wait for the recovery session to load — Supabase establishes it from the link on the PASSWORD_RECOVERY event.
4. Collect the new password and call supabase.auth.updateUser({ password: newPassword }) to complete the reset.
5. Confirm the Site URL is correct too — the reset link is built from it, so a wrong Site URL produces a broken link before your code even runs.

Related: Password-based auth & reset flow (Supabase docs)

How do I set the Supabase redirect URLs and Site URL correctly?

In the Supabase dashboard, open Authentication > URL Configuration and set two things. Site URL is your single canonical production URL and the default redirect when your code passes no redirectTo — it also builds the links inside confirmation and reset emails. Redirect URLs is the allow list of every URL a user may legitimately be sent to after auth. Get both right and most login failures disappear.

The allow list supports wildcards so you do not have to list every preview URL by hand: a single * matches one segment, ** matches any path, and ? matches a single character. That is useful for platforms like Vercel or Netlify that mint a fresh preview subdomain on every deploy — for example https://*-your-team.vercel.app/** covers them all. But keep the list tight: an over-broad pattern such as https://** would accept a redirect to any site on the internet, which is a genuine open-redirect security hole, not a convenience.

1. Set Site URL to your exact production URL, for example https://yourapp.com, with no trailing slash.
2. Under Redirect URLs, add your production URL, your Lovable preview domain, and your local dev URL (for example http://localhost:3000).
3. Use Supabase's wildcard patterns for preview deploys — for example http://localhost:3000/** and https://*-your-team.vercel.app/** — where ** matches any path.
4. Make sure every redirectTo in your code (OAuth, magic link, password reset) exactly matches an entry on this list.
5. Save, redeploy, and test each flow (Google, email confirmation, password reset) in an incognito window.

Related: Redirect URLs & Site URL configuration (Supabase docs) · stop Lovable environment variables vanishing on deploy

How do I tell which part of my auth is broken?

Reproduce the failure once with browser DevTools open and you can pin the layer in under two minutes. The Network tab shows whether the sign-in request or the OAuth callback actually completed. The Supabase dashboard logs show whether an email was attempted and refused. And the URL bar shows whether you were redirected to an unexpected origin — the tell-tale sign of a missing allow-list entry.

1. Open DevTools (F12), go to the Network tab, and enable Preserve log. Attempt the failing login once.
2. For Google: confirm the /auth/v1/callback request completes and note where it redirects. A redirect back to /login means the redirectTo was rejected by the allow list.
3. For email: in the Supabase dashboard open Authentication and read the auth logs for a message about a refused or rate-limited email send.
4. For password reset: click the emailed link and watch whether the reset page loads a session — no session means the redirect URL or Site URL is wrong.
5. Note the exact origin in the URL bar at the moment it breaks. If it is not your production domain, that origin is missing from Redirect URLs.

When should I stop and get help fixing Lovable auth?

If you have allow-listed every URL, configured custom SMTP, and wired the reset flow, and login still fails — or it fails only for some users, or only on the live domain — the problem is structural. Broken auth usually travels with other Supabase misconfigurations, and a login users cannot complete is lost revenue every hour it stays broken.

Auth misconfiguration is rarely alone. The same apps whose Google login is broken often also have redirect lists wide open to any origin, service keys sitting in the client bundle, or tables with no Row Level Security — the auth surface is exactly where security gaps cluster. That is why we treat a broken login as a reason to audit the whole auth and authorization layer, not just patch the one flow that surfaced.

We reproduce the exact failure with DevTools, fix the redirect, email, and session configuration by hand rather than by prompt, and check the rest of your auth surface for the leaks that usually accompany it — then hand you working, documented configuration you fully own.

Related: get a Lovable security audit of your auth and RLS · rescue a broken Lovable app fast