How to Add Login and Auth to an AI-Built App

Yes. Every major AI app builder generates a working login screen, complete with a sign-up form and a session, straight from a single prompt. That part is real. What doesn't follow automatically is the security behind it: Veracode's 2025 GenAI Code Security Report found AI-generated code introduced risky security flaws in 45% of tests.

The report tested output from more than 100 large language models across Java, JavaScript, Python and C#. Syntax pass rates have climbed as models improved. Security pass rates haven't moved with them, and Java showed the worst failure rate of the four languages tested.

The Cloud Security Alliance puts the range even wider: 45% to 70% of AI-generated code samples fail security tests, depending on method. Its research note names the pattern directly - authorization flaws, missing access controls and hardcoded credentials are the dominant failure modes. That's not a random slice of the codebase. That's the login system.

So the honest answer splits in two. The AI builds you a real login screen. It does not automatically build you a secured one. That's one piece of the larger gap covered in From Prototype to Launch: What Still Has to Be Built - and Joylo's AI Confidence Score runs a security audit on every plan and every build by default, which is exactly where a gap like this gets flagged before it ships.

Authentication and authorization are not the same control, and an AI-built app often only gets one of them right. Authentication checks who you are: a username, a password, a session. Authorization checks what that logged-in person can actually touch. A login screen proves the first. It says nothing about the second.

This is the single most-skipped step in a generated app, and it's a named category, not a guess. OWASP ranks broken access control as the number one risk in its Top 10, ahead of every other weakness class. OWASP's own definition: "Access control enforces policy such that users cannot act outside of their intended permissions."

The failure modes it names map straight onto a generated app: changing a URL to bypass a check, swapping an ID in a request to read someone else's record, tampering with a cookie or a JWT to look like a different, more privileged user. None of these show up in a demo where you're the only person testing. All of them show up the day a second real user signs up.

A login form that gates the front end and a database that answers anyone who asks are two different pieces of engineering. This authorization gap is exactly what Joylo's AI Confidence Score checks for under its security audit, on every plan and every build. See AI App Builders: Prototype Toys or Production Tools? for the fuller version of this split.

A named, public vulnerability record proves the gap: CVE-2025-48757, an insufficient Row-Level Security policy in Lovable through April 2025, scored 9.3 CRITICAL on the NVD's CVSS scale. It let remote, unauthenticated attackers read or write arbitrary database tables behind generated sites - past whatever login screen sat in front of them.

Lovable disputes the finding on the record: each customer, in its account, accepts responsibility for protecting their own application's data. That's a real dispute, worth taking at face value rather than picking a side. The Cloud Security Alliance counts 170 affected applications and names this exact CVE as its worked example of what authorization flaws and missing access controls look like in production.

Here's why the dispute itself is the point, not a distraction from it. The builder handed every one of those 170 apps a working login screen. The database rules behind that screen were left to each customer to configure, and in a lot of cases, nobody did. That split - the AI builds the door, you build the lock - is true of every AI app builder, not just Lovable. Replit, Bolt and the others ship the same kind of login screen. The database rules behind it are still yours to configure.

Judging any AI app builder on production-readiness comes down to a short, checkable list, not a marketing claim: - Does it turn on database-level access rules by default, the way Supabase's dashboard-created tables get Row-Level Security automatically, instead of leaving that switch for you to find? - Does it support login providers that already follow current standards, like RFC 9700's mandatory PKCE or the finished WebAuthn passkey spec, instead of routing you to a hand-rolled password form? - Does a security audit run on the code before it ships, the way Veracode and the Cloud Security Alliance research say generated code needs, rather than after a report like this one names the gap?

It's why Joylo's Expert Assist reviews check the database rules first, regardless of which builder generated the app. For the wider list of what else can go wrong before launch, see 7 Security Risks of Shipping an AI-Built App.

Enable Row-Level Security on every table your app exposes, then check it's actually running: Supabase's own docs state it plainly: "Tables and views exposed through the Data API without RLS can be accessed by any role with matching grants." Dashboard-created tables have RLS on by default. Tables created in the SQL Editor or by another tool do not.

Run this two-minute check today: open Supabase's Row-Level Security guide, go to Database > Policies for each table your app touches, and confirm RLS shows as enabled. If a table shows disabled, turn it on with ALTER TABLE public.<table> ENABLE ROW LEVEL SECURITY;, then write a policy for it - RLS with zero policies just blocks everyone, including you.

Building on Firebase instead? The equivalent lives in Security Rules. Firebase's documentation explains that authentication provides an auth variable your rules can read, null when a visitor isn't signed in. A rule protecting a user's own data matches request.auth.uid against the owning path; role-based access reads a custom claim from auth.token, for example request.auth.token.admin == true. How to Add Database Security to a Firebase Vibe-Coded App walks through this in more depth.

This is the check Joylo's engineers run first on every Expert Assist review: not whether the login screen looks right, but whether the tables behind it would let a stranger in if they skipped the screen entirely. It's the same client-side-versus-server-side gap covered in How to Connect an AI-Built App to a Real Backend - the database rules are the backend.

Use a login provider (Google, GitHub, or a passkey) instead of hand-rolling a password form, for most AI-built apps. Provider sign-in offloads password storage entirely and follows RFC 9700, the current OAuth 2.0 security standard, which most hand-built login forms in generated apps don't implement correctly.

RFC 9700 supersedes the older RFC 6819 and settles a decade of loose practice into one current rule set: PKCE is now mandatory on every authorization code flow, redirect URIs must match exactly, and the old implicit flow and password grant are formally deprecated. If your AI-built app's "sign in with Google" button skips PKCE or accepts a loose redirect match, it's running a pattern the IETF retired.

Passkeys are a live option now, not a preview. W3C Web Authentication Level 3 reached full Recommendation status on 25 August 2026, which means the spec behind Face ID and fingerprint sign-in is finished, not draft. Offering a passkey alongside a password gives phishing-resistant sign-in without asking a non-technical user to change habits overnight.

One more reason to reach for a provider first: it's one less password database for you to secure, hash and audit against a breach list, and one less custom flow for Joylo's engineers to re-check by hand during an Expert Assist review.

Hash passwords with Argon2id, never store them as plain text, and never write your own hashing function. NIST SP 800-63B-4 requires verifiers to store passwords salted and hashed with a suitable one-way key derivation function, support at least 8 characters minimum and 64 maximum, and block passwords found in breach lists.

It also drops the folklore: no forced composition rules (no more "must contain a symbol"), and no forced periodic rotation. Those two habits made passwords harder to remember without making them harder to crack.

For the exact numbers, OWASP's Password Storage Cheat Sheet gives checkable parameters: Argon2id at m=19456, t=2, p=1 as the first choice; bcrypt with a work factor of 10 or more; PBKDF2-HMAC-SHA256 at 600,000 iterations if you need FIPS-140 compliance. Its own line on why: "Using slow, memory-hard algorithms makes brute-force attacks significantly more difficult, expensive, and time-consuming."

Then there's the part generated code skips even when the password handling is right: the session that follows it. OWASP's Session Management Cheat Sheet requires the session ID to be renewed after any privilege-level change, at least 64 bits of entropy, and cookies set with Secure, HttpOnly and SameSite. Both an idle timeout and an absolute timeout are required, not optional. A login system that gets the hashing right and skips this still leaves an old session valid after a password reset, which defeats the reset - exactly the kind of parameter check Joylo's engineers run during an Expert Assist password-storage review.

Real teams close this gap by fixing the same short list of things, because AI-built apps break in the same places. 26 of 38 unique repair listings name a specific AI app builder in the title, 68% of the sample. A branded repair aftermarket already exists. Authentication is the first failure point builders name inside it.

Builders describe the same failure points across independent threads: authentication, database and payment integrations breaking, security holes shipped to production, and apps that held up in a demo but failed at first real traffic. That's Joylo's own research into the Fiverr repair market for vibe-coded apps, the Rescue Economy report, and it names the exact failure this guide has been walking through - a login screen that looked finished and a database that wasn't.

The engineering side of that fix has a name too. The same engineers behind Joylo built TrustDish's two-sided allergy-safe dining app at HST - a consumer app and a restaurant app, linked, from a standing start. It's the same job this guide walks through: take a login screen and a database and make them survive people who aren't the founder testing their own build.

For a reader who just found their own Row-Level Security gap using the two-minute Database > Policies check, Expert Assist is the fastest way to close it: a named engineer already in your codebase, first response inside 24 hours, a fixed price for 10 architect hours that never expire.

Test every user flow, including sign-up, log-in, password reset and log-out, not just the happy path. OWASP's Application Security Verification Standard gives you roughly 350 checkable requirements across 17 chapters, with authentication as chapter V6, and its Level 2 tier requires multi-factor authentication rather than leaving it optional.

Don't trust the client. OWASP's A01 Broken Access Control ranks this as the number one risk category for a reason - a check that only runs in the browser is not a check. Every rule that matters has to run again on the server, or in the database, where a user can't edit it out.

Don't hand-roll passwords if you can avoid it, and if you can't, follow NIST SP 800-63B-4 and OWASP's password storage parameters from Step 6 exactly, not from memory.

Joylo's AI Confidence Score runs a security audit like this on every plan and every build by default, alongside checks for scalability, reliability, integrations and code quality, and flags uncertain code before it reaches production. A human review of the auth flow and the database rules specifically, the kind an engineer runs by hand, comes through Expert Assist or a Co-Build plan. For the full pre-launch pass beyond just auth, see How to Security-Audit an AI-Generated SaaS Before Launch.

If you're ready to try this checklist on your own build, Joylo starts free, no credit card, and the AI Confidence Score runs on the first thing you generate. See current pricing for how the plans break down.

What Mistakes Do Teams Make When Adding Login to an AI-Built App?

The same five mistakes show up in almost every AI-built app we've reviewed. Trusting the front end to enforce rules the database never checks. Skipping Row-Level Security because the dashboard didn't ask for it. Hand-rolling password hashing instead of using a provider or a vetted library. Never renewing the session after a password reset. Treating MFA as a someday feature.

Each one has a specific fix: - Trusting the front end - re-check every permission in the database or the API layer, per OWASP's broken access control guidance. - Skipping Row-Level Security - open Database > Policies in Supabase, or the equivalent in Firebase's Security Rules, and confirm every table is covered, not just the ones the AI created through the dashboard. - Hand-rolling password hashing - switch to Argon2id at OWASP's published parameters, or better, hand password storage to a login provider entirely. - Skipping session renewal - regenerate the session ID on every privilege change, per OWASP's Session Management Cheat Sheet. - Leaving MFA optional forever - turn it on for any account holding payment data or personal records, which is most AI-built apps within a few months of launch.

Every one of these is also something Joylo's AI Confidence Score checks for by default before a build ships, and something Expert Assist checks by hand when you want a second set of eyes.

When Does This Login Security Framework Need to Change?

This checklist holds until one of three things changes: your app starts handling payment or health data, your user base crosses from a handful of testers into the thousands, or a standard itself moves, the way WebAuthn and NIST's password guidance already have in 2025 and 2026.

Scale changes the bar first. OWASP's ASVS Level 1 is a reasonable floor for an early build; Level 2, with mandatory MFA, is where an app holding real user data belongs, and Level 3's hardware-backed authentication is a regulated-industry conversation, not a default. Regulatory shifts change what you're allowed to skip, too: an app handling personal data needs the session and access-control rules in this guide treated as non-negotiable, not best-effort, since a broken access control finding on personal data is the exact scenario OWASP's A01 category exists to catch.

Standards move too, and recently. NIST retired password rotation and composition rules in SP 800-63B-4. W3C finished WebAuthn Level 3 in August 2026. RFC 9700 formally closed the door on the implicit OAuth flow. None of these were true five years ago. Joylo's AI Confidence Score re-runs its security check on every new build, which is one way to catch a standard shift like this without re-auditing the whole app by hand yourself once a year.

What Do Real Login Security Decisions Look Like in Practice?

What changes is the priority action, not the checklist: a solo founder fixes Row-Level Security first, a five-person team adds MFA and session renewal, and a builder who already found a gap calls in a second set of eyes to check the rest of the schema. Three concrete situations show exactly how that plays out.

A solo founder with a first version. No paying users yet, one login form, built in a weekend. Priority: turn on Row-Level Security or Firebase rules before the first sign-up form goes live, and add provider sign-in instead of a hand-rolled password field. This is a two-hour fix, not a redesign.

A five-person team past their first hundred users. Real accounts, real data, still self-serve. Priority: run the OWASP ASVS Level 2 checklist, confirm session renewal on password changes, and force MFA for any account touching billing. This is where an app moves from nobody checking to someone needing to check.

A builder who just found their own RLS gap. The database was open the whole time. Priority: fix the policy today using the two-minute Database > Policies check, then get a second set of eyes on the rest of the schema. This is what Joylo's Expert Assist exists for: a named engineer, already in the codebase, who treats a Tuesday-afternoon fix like a Tuesday-afternoon fix instead of a two-week ticket. If you've decided you need that kind of help, What Production-Ready AI App Building Actually Costs breaks down Expert Assist and Co-Build before you commit to either.