AI App Builder Built-In Auth (2026): Whose Login Screen Are Your Users Signing Into?

Quick Answer

In 2026, "built-in auth" is a yes on almost every AI app builder, and it is close to useless as a criterion. Our own matrix column for it reads yes for seven of the eight builders here, which means it separates nothing. Three questions do the separating, and all three are answerable from the vendors' own documentation:

1. Whose name is on the consent screen? Base44 says it plainly: its default Google login window "is branded with base44.com". Lovable says you only need your own credentials "if you want the consent screen to show your own branding". Replit "provides shared credentials out of the box". Your own branding is available in all three, and it is a separate project with its own bill.
2. Whose account is your user creating? With Replit Auth, "they are creating or using an existing Replit account" on a Replit-branded page. With Bubble or Base44, they are creating an account in your app. This is the single most consequential difference in the group and no yes-or-no column shows it.
3. What does the second week cost? Bolt.new has no managed mode at all, so you create the Google OAuth app yourself, and Google starts it in Testing status, "which limits sign-in to up to 100 users". Base44's custom OAuth needs a Builder plan, a payment method on your Google Cloud project, and a Google review that "can take up to 5 days". Replit's enterprise SSO is "free through October 1, 2026", after which Clerk's pricing is passed through to your bill.

And one correction that matters more than any of the above: Webflow no longer has built-in auth. User Accounts, originally called Memberships, was disabled on every Webflow site on January 29, 2026. Anything published after that date listing it as a Webflow feature, our own matrix included until today, is wrong.

The column that decides nothing

We built our AI app builder comparison matrix with built-in auth as criterion 4, and for most of a year it has been the least useful cell on the grid. Seven of eight builders answer yes. When a criterion returns the same value for nearly every candidate, it has stopped being a criterion and become a formality.

The reason it collapses is that "built-in" is doing two jobs at once. It can mean the vendor wrote the login screen for you, which is nearly universal and cheap. It can also mean the vendor owns the identity, which is rarer, deeper, and the thing you actually live with. A checkbox merges them.

So this page replaces the checkbox with the three questions above, scored per builder from primary documentation. Where a vendor states something against its own commercial interest, we quote it directly, because those are the sentences that survive contact with a real project.

Built-in auth across eight AI app builders, August 2026

Read the fourth and fifth columns together and the group splits cleanly in a way the yes-or-no column hides. Lovable, Replit and Base44 will lend you their own OAuth registration so login works this afternoon. Bolt, Softr and v0 will not, so your first login is gated behind a Google Cloud project you own. Neither is the right answer in general. They are different first weeks.

Question 1, whose name is on the consent screen

This is the question people discover after launch, in a support ticket, from a user asking why a different company is asking for their Google account.

Three vendors document the fork explicitly, and their wording is worth having side by side:

• Base44 is the most direct in the category. Default Google login is "fast setup using Base44's credentials", and "the login window shows 'Sign in with Google' and is branded with base44.com". Choose custom OAuth and "people will see your app's domain, not 'base44.com' when they sign in with Google".
• Lovable ships Google, Apple and Microsoft in "Managed by Lovable mode, where Lovable handles the OAuth configuration and security updates", and adds: "You only need your own credentials if you want the consent screen to show your own branding and verified domain."
• Replit provides "shared credentials out of the box" on Clerk Auth, and bringing your own "puts your app's name and branding on the sign-in screen".

The managed path is genuinely good engineering. Somebody else maintains the OAuth client and ships the security updates. The cost is that a user creating an account in your product sees a name that is not yours at the exact moment you are asking them to trust you. For an internal tool that is nothing. For a paid B2B product being reviewed by a procurement team, it is a conversation.

Then there is the third position. Bolt and Softr have no managed mode, so the branded path is the only path, and both walk you into the Google Cloud Console on day one. Bolt's own guide is candid about where that leads: "By default, Google sets your OAuth app's publishing status to Testing, which limits sign-in to up to 100 users." Until you complete branding, get it verified and publish the OAuth app, "only your domain appears on the sign-in screen", and "your app name and logo won't appear until you publish your branding, even after verification is complete".

Softr adds a wrinkle worth knowing before you pick a domain: on a Softr subdomain, the authorized domain you register with Google is literally softr.app. Connect a custom domain first and you register your own.

v0 sits outside the axis entirely, and it wins this particular question by not competing. There is no v0-managed OAuth client, because there is no v0 identity layer at all, so no v0 branding can appear on a screen you configured yourself.

Question 2, whose account is your user creating

Replit is the only builder in this group where the default answer is the vendor's. Its documentation does not hedge:

> Replit Auth uses Replit's own login system. When someone signs in to your app, they are creating or using an existing Replit account. The login page is Replit-branded, and the sign-in flow is the same one used across replit.com.

You can customise the app name, the icon and the enabled methods, but the docs are explicit that this is "customizable login page (with Replit branding)". There is also a detail that reads as a benefit and is worth reading twice: "any user that signs up via Replit Auth will automatically be added to your pending Replit Referrals". Your signups partly accrue to the platform as referral credit.

In exchange you get a real zero-setup product built on named infrastructure: Firebase and Google Cloud Identity Platform, reCAPTCHA for bot protection, Clearout for email validation, Stytch for MFA. Replit also sends the password reset emails, "so you don't need to set up your own email delivery provider". One more constraint: "The only way to implement Replit Auth is by using Agent. Manual implementation is not supported."

The alternative is on the same platform. Clerk Auth "gives your app its own dedicated authentication tenant powered by Clerk, with fully customizable branding and user accounts that are independent of Replit". Replit tells you which to pick if your brand matters. The gate is that Clerk dashboard access "is available on the Replit Pro plan".

Lovable has a narrower version of the same idea, aimed at internal tools rather than products: apps built for your own team "can recognize the signed-in workspace member with no login page at all". That is the vendor identity used deliberately, for the case where every user already has one.

Everywhere else in this group, the account is yours. Bubble is the clearest illustration of what that means structurally. User is a data type, but a privileged one, with three built-in fields that "can't be changed or deleted and are the same across all Bubble applications": Email, Password, and Email confirmed. The password field "is invisible even to you as the app developer", one-way hashed and salted. That single design decision buys you email confirmation, password reset, two-factor authentication, magic login links and temporary passwords without writing any of them.

Question 3, what the second week costs

Week one is a login button. Week two is the first enterprise customer, the first real consent screen, the first invoice. This is where the eight diverge most, and almost none of it appears in a feature comparison.

Two entries deserve expanding.

Base44's custom OAuth is a project, not a setting. The documented prerequisites are a connected custom domain, a verified domain in Search Console, a logo similar to your app's, a home page, a privacy policy linked from it, a support page, the domain registered as authorized, and the openid and userinfo.email scopes. Then: "You must add a landing page to your app that includes your privacy policy and terms of service. These pages must be public and not behind a login. This is required for Google OAuth approval." Then you wait up to five days. None of that is unreasonable. All of it is invisible in a yes.

Bolt's leaked-password protection is a portability trap in miniature. Bolt blocks passwords found in breaches using HaveIBeenPwned, "available on all Bolt plans and turned on by default when Bolt creates a database". But claim that database into your own Supabase organisation, or connect an existing one, and "password protection is available only if you have a Supabase Pro plan or higher. If you have a free Supabase plan, you'll see Prevent leaked passwords turned off." Taking the portable path silently downgrades a security default. That is the same shape we found in our AI app builder vendor lock-in scoring, where exercising portability costs you the platform's version history. A platform can only guarantee protections it fully controls.

Webflow is the correction, and the reason it happened is instructive

Webflow User Accounts, launched as Memberships, is gone. From Webflow's own sunset notice:

> On January 29, 2026, the User Accounts functionality will no longer be available on all Webflow sites in which it's currently in use. Additionally, you will not be able to add User Accounts to any new or existing sites, or call Webflow's User Accounts APIs and webhooks.

New enablement stopped a year earlier, on January 31, 2025. For sites still using it on the cutoff date, Webflow documented the outcome bluntly: you lose access to User Accounts and all User Accounts data "as it will not be migrated to the CMS", content gates are removed, and members can no longer log in. Webflow pointed customers at Outseta and Memberstack with migration discounts.

That was almost seven months before this page was published, and our matrix still said "Yes (Memberships)" this morning. Here is why that kind of error is so durable, and it is a genuinely useful thing to know as a reader of any comparison page: Webflow's own documentation still reads in the future tense. The overview article, timestamped August 2026, opens with "We're sunsetting Webflow User Accounts" and "On January 29, 2026, User Accounts functionality will be disabled". A fast read of a live vendor doc at HTTP 200 returns present-tense feature copy and a future-tense warning about a date that has already passed. Every roundup that checked the feature page rather than the calendar inherited the mistake.

We have corrected the matrix cell. We are also stating the rule we are adopting from it, because it generalises: a product's lifecycle usually does not live on its feature page.

The slugs that auth plants and you cannot take back

A second structural regularity, from two unrelated vendors, which suggests it is a property of the problem rather than a quirk of either.

Base44 hardcodes the reset path. When someone requests a password reset, "Base44 sends them an email with a link to /reset-password on your app's domain. That path is hardcoded and cannot be changed." The docs add: "Do not rename or move either page. If either page is missing, the password reset flow will break." The reset email itself "uses a standard Base44 template that cannot be redesigned".

Webflow was stricter, and this is from the overview page rather than the sunset notice: "Once you've enabled User Accounts, you cannot deactivate or remove it. You can't delete User pages or Collections after activating User Accounts. Additionally, you can't reuse the reserved URL slugs (e.g., /log-in, /sign-up)."

Turning auth on is a one-way door in your URL space. It is a small thing that becomes a real thing the day you want /login for something else, or you are planning an information architecture you intend to keep for years. Worth knowing on day one, when it costs nothing to plan around.

An honest note on the two we are hardest on

Bolt and Softr score worst on time-to-first-login in this scoring, and it is worth saying why that is defensible rather than lazy. Requiring your own OAuth client means there is no ambiguity about whose consent screen your users see, no shared client to be rate limited or reconfigured by a vendor, and no migration later when you outgrow the managed mode. Bolt pairs it with security defaults that are genuinely stronger than the group's: breach-password blocking on by default, reauthentication before password changes, confirmation from the old address before an email change.

And Softr's documentation does something we wish more vendors did: it warns you about its own convenience feature. Magic links "provide a permanent, pre-authenticated link", and "you should use magic links with caution, they are as good as an email and password. Anyone who has the link can log in as that user." You have to confirm you understand the risk before enabling them. That is a vendor choosing to slow you down.

Verdict, August 2026

If you need login working today and your users are internal: Replit Auth or Lovable's workspace identity reuse. Both hand you a working sign-in with zero OAuth configuration, and the vendor branding that disqualifies them for a consumer product is irrelevant when every user already has an account with that vendor.

If you are building a product with a brand to protect: Lovable or Base44. Both offer the managed path to launch fast and a documented route to your own consent screen later, which is the combination that matters. Read Base44's Builder-plan gate and five-day Google review before you promise a date, and note that Lovable is the only builder here offering end-user SAML SSO with no plan tier stated for it.

If enterprise SSO is a near-term requirement: Lovable first, on the plan-gating alone, then Base44 on Elite or Softr on Enterprise. On Replit, price it deliberately: SSO is free until October 1, 2026 and becomes Clerk pass-through pricing after, which is a budget question with a date on it.

If you already know your identity provider: v0. Its lack of a first-party auth layer is a real cost in week one and a real asset in year two, because nothing about your identity stack was granted to you by the builder.

If you want the deepest built-in user model: Bubble, and it is not close. Immutable auth fields, a password no one including Bubble can read, temporary cookie users whose data transfers on signup, two-factor authentication, magic links and temporary passwords, and per-user-field privacy rules. The trade is that it is Bubble's model, expressed Bubble's way.

Webflow is not a candidate for this criterion in 2026. Use Outseta, Memberstack or another membership tool, as Webflow itself recommends.

What to check before you commit

Each of these is answerable in minutes, from documentation, before you have users:

• Open the vendor's own sign-in screen for a test app and read the name on it. Not the marketing screenshot. The consent screen your users will see.
• Find the plan tier for your own OAuth credentials, and for SSO, separately. They are frequently different tiers, and neither is usually on the free plan.
• Ask what caps apply before the OAuth app is verified. Google's Testing status caps sign-in at 100 users, and X apps "start in development mode with limited users". Both are cheap to clear early and expensive to discover at launch.
• Check whether the reset and login paths are yours. If the vendor hardcodes /reset-password or reserves /log-in, plan your URLs around it now.
• Check whose account your user is creating. If the answer is the vendor's, decide whether you are comfortable with that before you have 500 of them, because moving identity is the hardest of the migration layers.
• Read the dated lines. Any sentence in a pricing or SSO doc containing a specific future date is a budget item. Replit's October 1, 2026 line is the live example in this group.

Where this fits

This scores criterion 4 of our AI app builder comparison matrix, and it is the build-time half of a question whose exit half we scored separately: identity is layer 3 of five in our AI app builder vendor lock-in analysis, which asks whether user accounts and their credentials can ever leave. The two answers are close to independent. A builder can give you a beautiful branded login and no way to take those users anywhere.

If your conclusion here is that you would rather own the identity layer outright, the comparison you want next is between the auth libraries themselves rather than the builders, and ShipGarden has scored those: Better Auth vs Auth.js vs Supabase Auth for Next.js.