How Do AI App Builders Handle Authentication?

The short version: AI app builders handle the easy 10% of auth - a login form and email/password via a provider like Supabase - well. They handle the hard 90% - authorization: roles, row-level security, session management, and reset edge cases - poorly by default, because a prompt does not specify who may see which records. That gap is where security holes appear.

Ask an AI app builder for "user login" and you get a login form: an email field, a password field, an SDK call wired to Supabase or Clerk, and a redirect to a dashboard. You can sign up, sign in, and sign out. From the outside it looks finished. It is not, and the reason is a distinction that "auth" hides inside a single four-letter word.

Authentication vs authorization: the distinction that matters

Authentication and authorization get collapsed into "auth," and that collapse is exactly where AI-built apps break.

Authentication is the process of verifying who a user is - checking a password, issuing a session token, identifying the person on the other end of the request. It is the login form. AI builders are good at this because it is a well-worn pattern with an SDK call at the center of it.

Authorization is the process of deciding what an authenticated user is allowed to do - whether they can read this row, edit this record, or hit this admin endpoint, and whether they should see a project that belongs to a different account. Authorization is per-resource, per-role, and specific to your data model, which means there is no generic SDK call that does it for you. Someone has to decide the rules and enforce them on every read and write.

Supabase's own documentation draws this line explicitly in its Auth overview: authentication verifies identity with a JWT, and authorization is enforced separately through row-level security policies on the database. AI builders give you the first half. The second half is a stack of decisions the tool never made because nothing in your prompt forced it to.

What AI builders give you by default

The default output is real work, and it is worth being fair about what it covers. Ask for login and a modern AI builder reliably produces:

• A sign-up and sign-in form with email and password fields.
• A provider integration - Supabase, Clerk, Auth0, or similar - that stores credentials and hashes passwords for you.
• A session token issued on sign-in and a redirect to a protected page.
• A sign-out button that clears the client.

That is the doormat in front of the door, and for a demo it is enough. One user signs up, clicks through, and everything appears to work. The trouble is that the demo runs with one person and a clean database, so the questions that authorization answers never come up.

The clearest way to see the gap is the incognito test. Sign up as user A and create some data - a project, an order, a note. Open a private window, sign up as user B with a different email, and load the same pages. If user B can see user A's data, your app authenticated the user but never authorized the request. The login worked; the access control does not exist. You can often shortcut this by opening the network tab as user B and watching the query the page fires. If it is select * from orders with no where user_id = ..., every signed-in user is reading the whole table.

What they leave to you

Everything past the login form is the part the AI skips, because a prompt for "login" does not spell out who may see which records. Four layers consistently go missing.

Row-level security. The fix for the incognito test is row-level security, or RLS - pushing the "who can read this row" rule down into the database itself so it refuses to return rows the current user is not allowed to see, no matter what query the app sends. Here is the trap, and the detail most guides get wrong: Supabase enables RLS by default on tables created through the dashboard Table Editor, but a table created in raw SQL or the SQL editor has it off unless you enable it yourself. AI builders generate schema in SQL. So the AI creates your orders table, RLS is never switched on, and every authenticated request can read and write the entire table. A minimal policy scopes reads to the owner:

alter table orders enable row level security;

create policy "users read their own orders"
on orders for select
using (auth.uid() = user_id);

You repeat that for insert, update, and delete, on every table that holds user data. Supabase's row-level security guide covers the policy syntax and the auth.uid() helper.

Roles and RBAC. Most real apps have more than one kind of user - an admin, a team owner, a member, a read-only viewer. "Is this person logged in" is a yes/no question; "is this person an admin" is a different one, and the AI almost certainly did not generate a role system because you did not ask for one in those words. Role-based access control attaches a role to each user and gates actions on it, and the critical detail is that those checks must live on the server or in the database, not the frontend. Auth0's RBAC documentation describes the roles-to-permissions model; on Clerk, route protection belongs in middleware so an unauthorized user never reaches the page handler.

Sessions and tokens. When a user signs in they get a token. Does it live in an httpOnly cookie or in localStorage where any injected script can read it? Does it expire? Does signing out actually invalidate the session server-side, or just clear the client and leave a valid token in play? The default the AI picks is rarely the secure one.

Password reset and email verification. The reset flow is a maze of edge cases: the link has to expire, be single-use, and never let an attacker reset an account they do not own. Email verification has its own gap - what happens to a user who signs up but never confirms. AI builders frequently leave that gap wide open. Supabase's password-based auth guide and social login guide walk through the reset, confirmation, and production redirect-URL configuration that close these holes. We go deeper on all four layers in adding authentication to an AI-built app.

The security risk in the gap

This is not a corner case, and it is not theoretical. When authorization is missing, the failure mode is broken access control - the most common category on the OWASP Top 10, and the one AI-generated code lands in most often.

The numbers are stark. Veracode's 2025 GenAI Code Security Report, which tested code from more than 100 large language models across 80 coding tasks, found that 45% of AI-generated code samples failed security tests and introduced an OWASP Top 10 vulnerability - and that newer, larger models were no better at security than older ones. This is a systemic property, not a bug the next model release fixes.

On the app side, a researcher who audited 50 vibe-coded apps across Lovable, Bolt, v0, Cursor, and Claude Code in early 2026 found that 88% had Supabase row-level security entirely disabled - the database would return any record to any query - and 24% had authentication logic inverted, locking out real users while letting unauthenticated visitors reach everything. A broader scan of 1,645 publicly listed Lovable apps found 170 of them, about 10.3%, with critical row-level security failures, leaking home addresses, financial data, API keys, and payment records (Lovable security report, Feb 2026). Every one of those apps had a login form that worked fine. We cover the full pattern in vibe coding security risks.

The common thread: the generated code trusts the client. It assumes the request came from the right user, asking for their own data, with permission to do what it is doing. Real security assumes the opposite and checks every time, as close to the data as possible.

How each approach handles it

Not every build path handles auth the same way. Here is how the three common ones compare on the part that matters.

The AI builder gets you to a login form fast and leaves the authorization decisions to you. A no-code platform hides more of it but boxes you into whatever access model the platform supports. A managed build treats authorization as a foundation rather than an afterthought - which matters because, as we explain in the 80% problem, access control shapes your tables and cannot be cleanly bolted on after launch.

Getting auth right

Whichever path you took, the finish line is the same checklist:

• The incognito test passes - user B cannot see user A's data on any page or API call.
• RLS is enabled on every table holding user data, with policies for select, insert, update, and delete.
• Roles exist if your product has more than one kind of user, and role checks run on the server or in the database, never only in the UI.
• Sessions live in httpOnly cookies, expire, and invalidate on sign-out.
• Password reset links expire and are single-use, and unconfirmed users cannot reach protected data.
• Social login redirect URLs are configured for your production domain, not localhost.

None of this is exotic. It is the standard, unglamorous work of access control - the 90% the demo never shows. AI app builders are genuinely good at authentication and genuinely blind to authorization, and knowing which is which is the whole point. If retrofitting the hard part cleanly is past a weekend's work, a managed build like Creatr ships the policies, roles, and session handling as production code rather than a prompt you keep re-rolling. Either way, the login form was never the hard part - now you know where the hard part actually lives.