Resolving Redirect Issues After Auth Flow in Lovable

Why OAuth redirects fail or loop after authentication in Lovable

When a user signs in with Google or GitHub in a Lovable app, the flow involves three parties: your app, Supabase, and the OAuth provider. The user clicks 'Sign in with Google', gets redirected to Google, approves the login, gets redirected to Supabase, and then Supabase redirects back to your app. If any URL in this chain is wrong, the user ends up on the wrong page or in a redirect loop. The most common mistake is leaving the Supabase Site URL set to http://localhost:3000 (the default). After the OAuth provider sends the user to Supabase, Supabase looks at the Site URL to decide where to redirect back. If it points to localhost, the user gets sent to localhost instead of your Lovable app — which either does nothing (blank page) or loops because the session never gets captured. Another frequent issue is having your production domain but not your Lovable preview domain in the redirect URLs list. Testing works on the published app but fails in the Lovable editor preview because the preview uses a different domain that is not whitelisted in Supabase.

• Supabase Site URL still set to http://localhost:3000 — redirects to localhost instead of your app
• Production domain not added to Supabase Redirect URLs — Supabase blocks the redirect as a security measure
• Preview domain and published domain are different — OAuth works on one but not the other
• Missing redirectTo option in signInWithOAuth — Supabase uses the Site URL instead of the intended page
• OAuth provider callback URL does not match the Supabase auth endpoint format

Error messages you might see

Before you start

• A Lovable project with Supabase authentication and at least one OAuth provider enabled
• Access to your Supabase project dashboard (Authentication Settings)
• Access to the OAuth provider console (Google Cloud Console, GitHub Settings, etc.)
• Your app's published URL and preview URL

How to fix it

1https://yourapp.lovable.app/**
2https://yourdomain.com/**
3https://id.lovableproject.com/**

const handleGoogleLogin = async () => {
  await supabase.auth.signInWithOAuth({
    provider: "google",
  });
};

const handleGoogleLogin = async () => {
  await supabase.auth.signInWithOAuth({
    provider: "google",
    options: {
      // Redirect back to the current domain's callback page
      redirectTo: `${window.location.origin}/auth/callback`,
    },
  });
};

1import { useEffect } from "react";
2import { useNavigate } from "react-router-dom";
3import { supabase } from "@/integrations/supabase/client";
4
5export default function AuthCallback() {
6  const navigate = useNavigate();
7
8  useEffect(() => {
9    // Supabase processes the OAuth tokens from the URL hash automatically
10    // We just need to wait for the session to be available
11    supabase.auth.onAuthStateChange((event, session) => {
12      if (event === "SIGNED_IN" && session) {
13        // Session captured — redirect to the app
14        navigate("/dashboard", { replace: true });
15      }
16    });
17  }, [navigate]);
18
19  return (
20    <div className="flex items-center justify-center min-h-screen">
21      <p className="text-muted-foreground">Completing sign-in...</p>
22    </div>
23  );
24}

Complete code example

1import { useEffect, useState } from "react";
2import { useNavigate } from "react-router-dom";
3import { supabase } from "@/integrations/supabase/client";
4
5export default function AuthCallback() {
6  const navigate = useNavigate();
7  const [error, setError] = useState<string | null>(null);
8
9  useEffect(() => {
10    const handleAuthCallback = async () => {
11      // Check if we have a session from the OAuth redirect
12      const { data: { session }, error: authError } = await supabase.auth.getSession();
13
14      if (authError) {
15        setError(authError.message);
16        return;
17      }
18
19      if (session) {
20        // Successfully authenticated — go to the dashboard
21        navigate("/dashboard", { replace: true });
22        return;
23      }
24
25      // If no session yet, listen for the auth state change
26      const { data: { subscription } } = supabase.auth.onAuthStateChange(
27        (event, session) => {
28          if (event === "SIGNED_IN" && session) {
29            navigate("/dashboard", { replace: true });
30          } else if (event === "SIGNED_OUT") {
31            setError("Authentication failed. Please try again.");
32          }
33        }
34      );
35
36      // Timeout after 10 seconds to prevent infinite loading
37      const timeout = setTimeout(() => {
38        setError("Authentication timed out. Please try signing in again.");
39        subscription.unsubscribe();
40      }, 10000);
41
42      return () => {
43        clearTimeout(timeout);
44        subscription.unsubscribe();
45      };
46    };
47
48    handleAuthCallback();
49  }, [navigate]);
50
51  if (error) {
52    return (
53      <div className="flex flex-col items-center justify-center min-h-screen p-8">
54        <p className="text-destructive mb-4">{error}</p>
55        <a href="/login" className="text-primary hover:underline">Back to sign in</a>
56      </div>
57    );
58  }
59
60  return (
61    <div className="flex items-center justify-center min-h-screen">
62      <p className="text-muted-foreground">Completing sign-in...</p>
63    </div>
64  );
65}

Best practices to prevent this

• Always set the Supabase Site URL to your production domain — never leave it as localhost
• Add all domains (preview, published, custom) to Supabase Redirect URLs with ** wildcard paths
• Use window.location.origin in redirectTo so the same code works in both preview and production environments
• Create a dedicated /auth/callback route to handle the OAuth return instead of redirecting to the home page
• Add a timeout on the callback page so users are not stuck forever if the session capture fails
• Register the Supabase callback URL (https://your-project.supabase.co/auth/v1/callback) in every OAuth provider console
• Test the full OAuth flow in an incognito window after every configuration change to avoid cached session interference

Still stuck?

Copy one of these prompts to get a personalized, step-by-step explanation.

Related error patterns