Adding Login and Google Sign-In to an AI-Built App

The one-sentence version: your AI coding agent wires it up, you check it's enforced

Asking your AI coding agent to "add login" usually gets you a real, working sign-up and login flow with very little effort, because the builder already has a login system to plug into. What doesn't come free is verifying that "logged in" actually controls what it's supposed to. This site's own guide to what authentication is covers the underlying concept; this page is about the practical gap between a login screen that works and access that's actually enforced.

What to ask for when you add login

A vague "add authentication" leaves your AI coding agent guessing at the scope. Name the pieces you actually need: sign-up, login, logout, password reset, and which pages or features need a logged-in user. Ask it to tell you which login system your builder uses and where the user accounts are stored, so you know what you'd be taking with you if you ever move the app. Here's a prompt to copy and adjust:

Add user accounts to this app.

1. Sign-up, login, logout and password reset, using the login system this platform already provides. Tell me which one that is and where user accounts are stored.
2. These pages need a logged-in user: [list them]. Send everyone else to the login page.
3. Protect the data, not just the pages: add access rules in the database so each user can only read and change their own records. Show me the rules you added.
4. [Only if you want it] Add "Sign in with Google". Then tell me exactly which addresses I need to register myself, and where each one goes (Google's console or the login service's settings): the local testing address, the preview address and the live site address.
5. Before you call this done, tell me how to test each point above as a logged-out visitor and as a second user.

What to check in its answer

• It names the login system and where accounts live. "It's handled" isn't an answer.
• It shows you real access rules on the data (point 3), not only pages that redirect to the login screen.
• If you asked for Google sign-in, it lists each address and where it goes, and says plainly that registering them is a step it can't do for you.

The mistake that ships more often than it should: a role check that only hides UI

This site's own guide to why you can't put an API key in the frontend covers the exact same underlying rule with a worked example already: a client-side "is this user an admin" check can be edited in the browser's own dev tools before the request is even sent, the same way a client-side discount-code check can be bypassed by anyone willing to look. An authentication check that only decides whether to render an admin menu, without the actual admin action being separately verified server-side, has the identical shape of bug. It looks correctly locked down in normal use and fails silently the moment someone deliberately checks.

Protecting data behind a login: an access rule in the database

This site's own guide to when your app actually needs a database covers Row Level Security as the first setup step once a table exists; the same rule is what turns "logged in" into something that actually restricts data, not just what's displayed. An access rule that checks a row's owner matches the logged-in user (Supabase calls this Row Level Security; in Base44 you set read and write permissions on each type of data) means the database itself refuses a request from anyone other than the right user, independent of whether the frontend ever tried to hide that data from them in the first place. This is the enforcement layer a hidden button alone can never provide.

Sign in with Google: the step your AI can't do for you

Your AI coding agent can write the code that sends a visitor to Google and handles them coming back. That part is ordinary code. What it can't do is register your app with Google. Google only sends a signed-in visitor back to an address (called the redirect URI) that's on your app's list in Google's own console, and that list lives in your Google account, not in your builder's chat. If the address doesn't match one on the list exactly, Google refuses the sign-in. That's why "add Google login" so often gives you a button that looks finished and fails on the first click: the code was never the missing piece.

Some builders offer a managed option that uses the builder's own Google registration, so there's nothing for you to set up. On some of them, Google's sign-in screen then shows the builder's name rather than your app's, so check what yours shows before you launch. If you'd rather control it yourself, you bring your own Google credentials, and the registration becomes your job.

Localhost, preview and live are three different addresses

Every address your app runs from has to be allowed somewhere. On most projects that's three: localhost while you test on your own computer, the builder's preview address, and your live domain once you connect your own domain. Where they go depends on how your app is wired:

• Your app talks to Google directly: each address goes on your app's list in Google's console. Google's list doesn't accept a wildcard, so each one is listed separately.
• A login service sits in between (many builders use one): Google's list holds that service's own callback address, and your app's addresses go on the login service's list of allowed redirect addresses.

Either way, sign-in working on localhost only proves the localhost setup is right. It says nothing about the preview or the live site.

What each sign-in error usually means

A simple checklist before you consider auth actually done

Five things worth confirming before treating a login feature as finished:

• Sign-up, login and logout all genuinely work, tested as a real visitor would use them, not just glanced at in your builder's own preview.
• Every page or feature meant to require login actually checks for it, not just the ones you remembered to test.
• Any data a specific user's account should keep private has a real access rule behind it, not just a hidden link to reach it.
• Any admin-only action is verified on the data side, not decided by which menu items happen to be visible to the person making the request.
• If you added Google sign-in, it works on the live domain, tested with a Google account other than your own.

The quickest real test: open a private browser window, sign up as a second user, and try to open the first user's page or record by its link. If you can see it, the data isn't protected yet, whatever the menus show.

Not every project needs a full account system

A single-purpose internal tool, a quick prototype, or an app with genuinely nothing private to protect gets little from a full sign-up-and-login system built in from day one. Adding real authentication is worth doing the moment an app actually has user-specific data or an action that must be restricted to a specific person, not as a default first step on every new project regardless of what it actually needs to protect.