Why Authentication Breaks in AI-Built Apps (And How to Fix It)

Authentication is where AI-generated code fails most dangerously. Not because the login form looks wrong. It usually looks great. The problem is everything behind it: how sessions are stored, how tokens are handled, how permissions are enforced, and what happens when a user refreshes the page.

We have fixed auth in dozens of AI-built apps. The patterns are remarkably consistent regardless of whether the app was built with Lovable, Claude, or Cursor. Here are the specific problems and what to do about each one.

1. Sessions that vanish after refresh

This is the most common one. A user signs in, everything works, they refresh the page, and they are logged out. The root cause is almost always that the app is storing auth state in React state or a simple useState hook instead of actually checking the session with the auth provider.

Lovable apps using Supabase are especially prone to this. The generated code often sets a "user" variable after login but never calls supabase.auth.getSession() on page load. So the app has no way to know the user is still logged in after a refresh.

The fix: Set up an auth state listener that runs on app initialization. For Supabase, that means calling onAuthStateChange and getSession in a layout or provider component. For NextAuth, make sure your SessionProvider wraps the entire app.

2. Custom auth instead of using the built-in system

We see this constantly. The AI tool generates a custom login system with bcrypt password hashing, manual JWT creation, and token storage in localStorage. Meanwhile, the project already has Supabase or Firebase set up with a perfectly good auth system that is being completely ignored.

Custom auth is one of the easiest things to get wrong. Token expiration, refresh logic, secure storage, CSRF protection. Each one of these is a potential security hole when you roll your own.

The fix: If your project has Supabase, Firebase, Clerk, or any managed auth provider, use it. Rip out the custom implementation. The migration is usually a day or two of work and eliminates an entire category of bugs.

3. Tokens stored in localStorage without encryption

AI tools love putting tokens in localStorage. It is the simplest solution and it works. But it also means any JavaScript running on your page (including third-party scripts, analytics tools, or an XSS vulnerability) can read your users' auth tokens.

The fix: Use httpOnly cookies for token storage. Most auth libraries handle this automatically if you use their built-in session management. If you must use client-side tokens, keep them in memory (not localStorage) and use short expiration times with refresh tokens.

4. OAuth that works locally but fails in production

Google login, GitHub login, Stripe OAuth. They all work perfectly on localhost:3000. Then you deploy and get a redirect URI mismatch error. This happens because the OAuth provider has a whitelist of allowed redirect URLs, and your production URL is not on it.

But that is just the obvious case. The subtler version is when the redirect works but the callback handler fails silently. The user gets sent to a blank page or loops back to login. This usually means your callback route is not properly exchanging the authorization code for a session.

The fix: Add your production URL to every OAuth provider's allowed redirect list. Then test the entire flow in production, not just the login button click, but the redirect, the code exchange, and the session creation.

5. No row-level security or permission checks

The user is logged in. Great. But can user A see user B's data? In most AI-generated apps, the answer is yes. There are no permission checks on API routes, no row-level security policies on the database, and no middleware validating that the requesting user has access to the requested resource.

This is not just a bug. It is a security vulnerability. If your app handles any kind of user data, payment information, or private content, this needs to be fixed before launch.

The fix: For Supabase projects, enable row-level security on every table and write policies that scope queries to the authenticated user. For API-based backends, add middleware that validates the user's session and checks ownership before returning data.

6. Password reset and email verification not wired up

AI tools often generate a "Forgot Password" link that goes nowhere. Or an email verification flow that sends an email with a link that 404s. The UI exists but the backend logic was never completed.

The fix: If you are using a managed auth provider, these flows are usually one configuration step away. Supabase has built-in email templates. Firebase handles it automatically. The work is connecting the redirect URLs and making sure your app handles the callback route correctly.

How to know if your auth is actually broken

Run through this checklist:

• Sign up, log out, refresh, and log back in. Does the session persist across page refreshes?
• Open two browser tabs as different users. Can user A see user B's data by changing the URL?
• Deploy to production and test every auth flow again. Do they all work identically to localhost?
• Check your browser's developer tools for tokens in localStorage. Can you find raw JWT tokens or API keys?
• Try accessing an authenticated API route without a session. Does it return data or a 401?

If any of these fail, your auth needs work before you can safely launch.

You do not need to figure this out alone

Auth is the single riskiest piece of any app. Get it wrong and you are exposing user data, breaking trust, and creating legal liability. But the fixes are well understood and usually take days, not weeks.

If your login works sometimes, your sessions are flaky, or you are not sure if your user data is actually protected, we can look at it and tell you exactly what needs to change.