Why login doesn't work in your AI-generated app

Updated June 2026 · 7 min read

Auth is the most-broken system in every vibe-coded app we see, because it's the one system that's bound to where the app runs — and your app just moved. It worked in the Lovable or Bolt preview because the tool configured auth for the preview's domain. Here are the five failures, with the tell-tale symptom for each.

1. OAuth redirects to the wrong place (or errors out)

Symptom: you click "Sign in with Google/GitHub," approve, and land on an error page, a redirect_uri_mismatch, or back at your app with ?code=... in the URL and no session.

OAuth providers only redirect to URLs you've explicitly registered. The preview domain was registered; your new domain isn't. Fix it in two places: the provider's console (Google Cloud / GitHub OAuth app settings) needs your auth callback URL, and your auth platform (Supabase, Clerk, Convex Auth) needs your site URL so it knows where to send users after the handshake. Getting these two confused — putting the site URL where the callback belongs — is the single most common auth bug we fix.

2. The site URL still points at the preview

Symptom: after signing in (or clicking an email confirmation link), users get dumped on localhost:3000 or a dead preview URL.

Auth platforms keep a "site URL" setting used for all redirects. In Supabase it's Authentication → URL Configuration. Set it to your production domain, and add any additional domains (staging, previews) to the allowed redirect list.

3. Email confirmation is on, but emails never arrive

Symptom: sign-up "succeeds," then the user can never log in — they're stuck unconfirmed.

Supabase's built-in email has a tiny rate limit meant for development. In production you need a real SMTP provider (Resend, Postmark) wired into your auth platform, with your domain verified. Until then, either disable email confirmation or accept that only a few sign-ups per hour will ever get a confirmation email.

4. Sessions vanish on refresh

Symptom: login works, then a page refresh logs the user out.

Usually the AI wired auth state into React component state without persisting/restoring the session, or cookies are misconfigured for the new domain (wrong domain attribute, missing Secure on https). The fix is using the auth SDK's built-in session persistence rather than the hand-rolled version the AI invented.

5. The login screen is a costume

Symptom: everything "works," suspiciously well.

The most dangerous one. The UI gates pages on the client — but the API routes and database accept requests from anyone, logged in or not. The login screen is theater; the data is public. Test it: call one of your API endpoints with curl, no cookies, and see what comes back. Every route that touches user data needs a server-side auth check, and your database needs row-level security that actually scopes rows to the signed-in user. This is the first thing we audit on every app that comes through the shop.

The repair order

Fix them in this sequence — each one masks the next: provider callback URLs → platform site URL → email delivery → session persistence → server-side enforcement. Budget an afternoon if you're comfortable in dashboards and code; the security item (#5) is the one worth paying for if you're not, because getting it wrong is invisible until it isn't. (What that costs.)