A Lovable login loop is usually not a reason to rebuild authentication from scratch.
If Google sign-in completes but sends you back to /login, email confirmation opens the wrong domain, password reset lands on localhost, or authentication works in Lovable preview but fails on your custom domain, treat the problem as a chain of redirects and session state.
The useful debugging model is:
your app → identity provider → Supabase callback → allowed app URL → session establishment → route guard → destination
Find the first step that is wrong. Do not ask an AI builder to rewrite every auth component until you know where the state is being lost.
First, identify the exact failure
Different symptoms point to different layers.
| What you see | Check first |
|---|---|
| Google rejects the callback | OAuth provider callback configuration |
| Login finishes but returns to localhost | Supabase Site URL and redirectTo |
| Preview works, custom domain fails | Production redirect allow list and environment URLs |
| User returns to the app but is sent straight back to login | Session loading and route-guard logic |
| Email confirmation opens the wrong site | Supabase Site URL, redirect URL and email template |
| Password-reset link opens but cannot reach the update-password page | Reset redirectTo and allowed redirect path |
This distinction matters because a beautiful new login screen cannot fix an incorrect callback URL.
1. Check Supabase Site URL
Supabase’s current Redirect URLs documentation says the Site URL is the default redirect destination when your code does not specify redirectTo.
For a production app, that normally means the Site URL should be your real production origin, for example:
https://app.example.comnot:
http://localhost:3000This setting is especially important for email confirmations and password resets.
If your Lovable project worked while developing and later moved to a custom domain, an old Site URL is one of the first things worth checking.
2. Check the Redirect URLs allow list
A redirectTo value does not become valid just because your frontend requests it.
Supabase requires that destination to match the project’s configured Redirect URLs. Its documentation recommends exact production redirect paths rather than relying on broad wildcards in production.
List the real flows your application needs. They might include:
https://app.example.com/auth/callback
https://app.example.com/account/update-passwordPreview and local environments can need their own entries while you are developing.
The principle is simple: development convenience should not become an unnecessarily broad production allow list.
3. Do not confuse Google’s callback with your app’s final redirect
This is where OAuth configuration becomes confusing.
For Google sign-in with Supabase, Google’s authorized redirect URI points to your Supabase Auth callback endpoint. Supabase’s current Google sign-in guide tells you to use the callback URL shown on the Google provider page in your Supabase dashboard.
That is not necessarily the same URL where you want the user to finish.
Think of it as two hops:
- Google → Supabase callback so Supabase can complete the provider exchange.
- Supabase → your app using the allowed destination for the sign-in flow.
If you put the wrong URL into the wrong system, you can spend hours changing frontend code that was never the problem.
4. Verify what the frontend actually passes as redirectTo
Do not assume the generated code uses the domain you expect.
Inspect the call to signInWithOAuth, signUp, resetPasswordForEmail or the relevant auth method. Then compare its destination with the Supabase allow list.
For OAuth, Supabase documents the pattern explicitly: the redirectTo URL should point to your callback/destination and be included in the Redirect URLs configuration.
Watch for hard-coded development origins such as:
localhost:3000
old-project.lovable.app
an obsolete staging domainA custom domain migration can expose these leftovers even when the UI itself did not change.
5. If the user returns correctly, inspect session handling before redirects
Suppose the browser returns to the correct production URL, but the app immediately throws the user back to login.
At that point, DNS and the provider callback may already be working.
The next question is whether your protected route waits for authentication to finish loading.
A robust route decision has at least three states:
- authentication is still loading;
- a valid signed-in session exists;
- loading has finished and there is no session.
If generated code treats the first state as the third, a protected page can redirect before Supabase has restored the session. The result looks like failed login even though the provider exchange succeeded.
This is why I prefer debugging auth as a state machine, not as a login-page design problem.
6. Test email confirmation separately from OAuth
Email confirmation is a different path through the system.
Supabase’s password authentication documentation allows a confirmation redirect URL during signup, and that URL must be configured as an allowed Redirect URL.
Supabase also notes that email templates may need to use the redirect destination when you supply redirectTo rather than always relying on the Site URL.
So test these independently:
- New email/password signup.
- Confirmation link.
- Existing-user login.
- Password reset.
- Google or other OAuth login.
- Hard refresh while signed in.
- Logout and login again.
One successful flow does not prove the others are configured correctly.
7. Test production like a new user
Old browser state can hide auth bugs.
After changing URLs, test in a fresh private window. Use a test account and follow the complete journey from the production domain.
Record the URL at each transition. You are looking for the first unexpected origin, path or redirect.
Also test a hard refresh on a protected page after login. If the user is authenticated until refresh and then loses access, you may have a session-restoration problem rather than an OAuth callback problem.
8. Do not fix auth by weakening security
A frustrating redirect bug can tempt you to disable controls until the app “works.” Avoid that shortcut.
Do not expose a Supabase secret/service-role credential in browser code. Do not disable Row Level Security just to make an authenticated page load. And do not turn a precise production redirect policy into an unrestricted wildcard unless you understand the security consequence.
My Supabase anon-key guide explains the difference between a client-safe publishable/anon credential and privileged server credentials.
For the wider launch audit, use the AI-built app production checklist.
A practical order for fixing the loop
Work in this order:
- Confirm the production domain itself loads.
- Identify the auth method that fails.
- Check the OAuth provider callback if social login is involved.
- Check Supabase Site URL.
- Check the exact Redirect URLs allow list.
- Inspect the frontend’s
redirectTovalue. - Confirm the returned URL is correct.
- Confirm Supabase establishes/restores the session.
- Confirm route guards wait for auth loading to finish.
- Retest confirmation, reset, refresh and logout independently.
That sequence narrows the fault instead of creating five new ones.
When to stop prompting and inspect the system
AI builders are very good at producing authentication UI quickly. The difficult part is that production authentication crosses several systems with separate configuration and authority.
If repeated prompts keep changing components but the browser still follows the same wrong redirect, stop prompting for visual fixes. Inspect the URL configuration, callback chain and auth state directly.
That is also the point where a developer handoff becomes useful. My Lovable developer handoff guide explains what should exist before another developer takes responsibility for the app.
If your Lovable or Supabase app is already built but authentication, permissions, deployment or production state is unreliable, see my MVP development service or contact me. The goal is not to replace working software. It is to find the boundary that is actually failing and make it dependable.
