Adding User Authentication to an AI-Built App Without Code

Building a client portal or internal tool with AI and no developer comes down to one decision: pick a platform where authentication is bundled in from the start, or accept that you'll be wiring together a database, an identity provider, and an OAuth intermediary by hand. The first path gets a working login screen in minutes. The second can stall a project for weeks, because the founder ends up learning OAuth, Supabase, and the Google Cloud Console just to let one user sign in.

What authentication tests in a platform built for non-technical founders

Most non-technical founders building AI-assisted apps hit the same wall at the same moment. The interface looks done. The prompts have worked. Buttons click, pages load, and then it's time to let an actual user log in, and the platform either handles that invisibly or hands the problem straight back. Nothing before this point has tested whether the platform was really built for someone without a engineering background. Login is where that gets tested.

Everything that makes an app real, meaning user data, personalization, permissions, billing, depends on the system knowing who is logged in. Get that wrong, or get stuck trying to set it up, and nothing downstream works either.

What user authentication requires under the hood

Authentication and authorization get used interchangeably, but they answer different questions. Authentication identifies who a user is. Authorization controls what that identified user is allowed to do. A production-ready app needs both, and they have to be built as separate layers, because a system can correctly identify a user and still let that user see data they shouldn't.

A working login system needs a specific set of pieces, at minimum: a login interface, a database of user accounts, session management to keep someone logged in as they move between pages, a way to handle passwords or exchange OAuth tokens, and routes that block anyone who hasn't logged in from reaching protected pages. A system missing any one of these pieces is incomplete, even if the login screen itself looks finished.

"Sign in with Google" Sign in with Google" runs on OAuth, a three-party handshake between the app, an identity provider like Google, GitHub, or Apple, and an auth intermediary that sits between them. All three have to be configured so each one trusts the others, and that configuration is where a surprising amount of setup time disappears.

Even a correctly authenticated login doesn't guarantee safety. Row-level security, the rule that stops one logged-in user from reading another user's data, sits on top of authentication as its own separate layer. An audit of 26 third-party apps conducted in June and July 2026 found that most of them were missing it. In seven of those apps, a logged-in user could read or write another customer's data. Those are production apps, not prototypes: a login screen that works and an app that's actually secure are two different achievements.

The two structural paths available to a non-technical founder building with AI

Every AI-assisted app-building environment eventually resolves to one of two approaches. Either the platform owns the entire auth stack, or the founder has to wire it together from outside services.

In the bundled approach, the platform generates data models, authentication, permissions, and deployment in a single step. The founder never opens a Supabase dashboard or a Google Cloud Console, because the platform has already made those decisions. Base44 is the clearest example of this model at work: it was acquired by Wix in June 2025 for $80 million after just six months of operation, and it generates a complete app, database schema, authentication, and UI included, from a plain-English description, handling all the backend detail out of view. Zite works on the same principle. A test build of an employee onboarding portal produced login screens, role-based access, and a connected database in a matter of minutes, with no external service to configure.

In the stitched approach, the AI builder generates the frontend and the application logic, but identity management still requires connecting a dedicated service, Supabase, Clerk, Firebase Auth, or Auth0, by hand. That means configuring OAuth client IDs, redirect URIs, and callback URLs across at least three separate systems. The actual sequence looks like this: get a Client ID and Client Secret from the Google Auth Platform console, create an OAuth client ID scoped to a web application, then paste the callback URL into the auth provider's own settings. Each of those steps happens in a different dashboard the founder has likely never opened before. This three-system handshake, AI builder, auth provider, identity provider, is where most non-coders get lost, because an error in any one of the three systems produces no useful error message in the others.

Floot runs on the same logic as the bundled platforms, but from inside the AI tools founders already use. It plugs into Claude or ChatGPT directly and handles backend logic, database storage, user authentication, and hosting automatically, so auth never becomes its own separate configuration step.

Both paths produce a working app. Only one of them produces a working app without asking the founder to become, briefly, a backend engineer.

Why stitching in auth from outside the platform is harder than it looks

External auth services like Supabase, Clerk, and Auth0 are legitimate, well-built tools, but AI assistance makes it easy to start the integration without removing the failure modes that show up once the setup spans multiple outside systems.

Take the state parameter, the small piece of OAuth code that exists specifically to prevent cross-site request forgery attacks. AI tools skip it roughly half the time. The login still works. Nothing looks broken. The gap stays invisible until a security incident exposes it, so the founder has no way of knowing the flow is incomplete just by testing it.

OAuth itself carries dozens of vendor-specific quirks, token-refresh race conditions, and behaviors that aren't documented anywhere obvious, and people who've deployed auth at scale generally advise against building it from scratch, no matter how capable the AI builder seems. That advice holds even when the code looks clean, because the failure modes surface under conditions a founder isn't testing for.

There's also a slower-moving risk building up across the industry. A Material Security study of OAuth-connected apps found that most AI and automation apps had appeared in just the past 16 months, and close to half had sat dormant for an extended stretch without being removed or revoked. Those dormant grants from abandoned or lightly maintained AI-built apps are turning into a real attack surface for the businesses and users connected to them, and a login screen never reveals it.

Stitching auth together yourself offers more long-term flexibility and a lower cost ceiling than a bundled platform. But that flexibility comes at the cost of a configuration burden and a security exposure, carried by a founder who, in most cases, hasn't yet confirmed the product is worth that investment.

The external auth service market

Competition among the dedicated auth providers has pushed most of them toward generous free tiers, which is part of why "just stitch it in, it's free" feels like a safe assumption early on. It isn't as safe as it sounds once a product actually gets users.

Once an app passes the point where free tiers end, the pricing gap between providers opens up fast, and it opens unevenly. Supabase tends to stay cheap at that point, while Clerk becomes notably more expensive at the same user count. Among indie hackers in 2026, Supabase has become something close to the default choice, in large part because its free tier includes email login, password reset, OAuth providers, magic links, and session management, all at no cost up to a set monthly active user threshold.

The costs that catch founders off guard are usually the ones they never budgeted for in the first place: SSO, advanced multi-factor authentication, and per-MAU overages often get mentally filed under "auth is free," until they appear as line items on an invoice. Clerk does allow exporting user data, including hashed passwords, but users still have to re-login, though not re-register, if a founder later migrates away. That's a manageable inconvenience for a small app and a genuine constraint once the user base has grown.

The typical indie-hacker stack in 2026, Cloudflare Workers, Supabase or Neon for Postgres, Resend for email, PostHog for analytics, can run for close to nothing a month, auth included. That number assumes every one of those services has already been configured correctly, and configuring them correctly is what takes the time.

How MCP connectors change the auth picture

MCP, short for Model Context Protocol, introduces a different workflow than either of the two paths above. Instead of the app authenticating its users directly, the AI tool itself authenticates to external services on the user's behalf, under OAuth 2.0 managed at the connector level.

The mechanics are specific. A user adds a remote MCP server URL under Claude's Settings, then Connectors, authenticates through OAuth 2.0, and Claude stores the resulting credentials securely. That grants the connector a user-scoped access token from the source system, so the connector ends up enforcing the same access rules the underlying app already has in place. On Team and Enterprise Claude plans, the permission model is split: an Owner configures connectors at the organization level, and then each member connects individually, unless Enterprise-managed auth is used, in which case the Owner authorizes a connector once and members inherit access automatically on first login. That design keeps Claude limited to data each person already has a legitimate right to see. In Cursor, the setup runs through a .cursor/mcp.json file placed in the project root, followed by enabling the connector in the sidebar and completing the OAuth sign-in.

Anthropic opened an official submission portal on September 25, 2026, so anyone on a paid Claude plan can submit an MCP connector or plugin bundle to the Claude directory and track its usage after publication, with no Anthropic partnership required. That's lowered the barrier for connectors to exist, which has raised a new question for whoever builds them.

MCP OAuth introduces a security concern that ordinary web authentication never had to account for: prompt injection used as a way to exfiltrate tokens. The protections that already exist in web OAuth, PKCE, short-lived tokens, least-privilege scopes, token audience binding, apply just as much to MCP agents, and it falls to whoever builds the connector to implement them. That responsibility doesn't disappear just because the protocol is newer.

Floot's role in this picture is specific. As an MCP connector, it handles the infrastructure in the background so a founder building inside Claude or ChatGPT gets user authentication, database storage, and hosting without leaving the conversation at all. The MCP layer is absorbing the exact complexity that the stitched-auth path leaves sitting with the founder.

Deciding which path fits your situation

The right path comes down to three questions: where are you already building, how much of the backend do you actually want to manage, and does auth need to be live before you've confirmed anyone wants the product.

Working inside Claude or ChatGPT already, an MCP connector such as Floot is the straightforward infrastructure choice. It meets the founder where the work is already happening, handles auth automatically, and removes the configuration surface where most non-technical builders get stuck.

Building in a standalone AI app builder instead, the platforms with bundled auth generate authentication alongside the data model and the UI in one step, cutting the setup to nothing and removing the three-system handshake entirely. Base44 reached 250,000 users within six months of launch according to its own growth figures, and Zite's production-ready auth setup is another example of this model holding up at real scale.

Stitching together an external service like Supabase, Clerk, or Auth0 makes sense once user demand has already been validated and the founder needs something specific that a bundled platform doesn't offer: granular permission control, a custom identity provider, or enterprise SSO. Doing that work before validation front-loads a configuration burden and a real security exposure onto a product that hasn't yet proven it needs either. Memberstack showed years ago that no-code authentication could run on static sites through simple HTML data-attributes, proving that this complexity can be abstracted away entirely. Whether the platform or the founder does that abstracting is the only open question.

The audit findings from earlier make the stakes concrete. In seven of 26 apps reviewed, a logged-in user could read or write another customer's data, and in eleven, unauthenticated endpoints were doing privileged work. A login screen that works and an authentication system that's actually secure are not the same thing, and the platform a founder chooses is what decides which one ends up shipped.