Every platform on this site claims to “have authentication.” That word covers a login form with nothing behind it and it covers a full set of pre-built recovery, verification, and session flows. Buyers who stop at the checkbox find out the difference after launch, usually when a real user gets locked out and there is no password reset page to send them to. This guide breaks down what the claim should actually mean, and how to check it before you sign, tied to the Security & access control criterion scored at /methodology.
The checkbox hides eight separate decisions
“Has authentication” is really a bundle of independent flows, and a platform can ship some of them while quietly skipping the rest:
- Login and signup pages - the visible part every platform demos.
- Password reset - a self-service flow, not a support ticket, for the account you did not create.
- One-time passcode (OTP) - email or SMS codes as an alternative to a stored password.
- Magic links - passwordless login via a single emailed link.
- Two-factor authentication (2FA) - a second verification step beyond the password.
- SSO (SAML/OpenID) - login through the buyer’s existing identity provider, common in enterprise procurement.
- Domain-restricted or invite-only signup - controlling who is allowed to create an account at all, not just who can log in once they have one.
- Session handling and forced logout - how long a session stays valid and whether an admin can end it.
A platform that “has authentication” might ship all eight as toggles, or it might ship only the first item and leave the other seven for you to build. Both are honestly described as “has authentication” in a sales conversation. Only one of them is production-ready.
Why AI generators build the login page and skip the rest
AI code generators are excellent at building exactly what a prompt describes, and a prompt rarely describes password recovery. The tools optimize for the happy path: a clean login screen and a working dashboard, because that is what a demo needs and what the builder explicitly asked for. Password reset, OTP verification, domain restrictions, and session expiry are secondary flows nobody thought to prompt for, so they get skipped by default.
The gap is invisible during the build. The app runs, the login works, the demo looks finished. It becomes visible the first time a real user forgets their password and there is no recovery page, or the first time an ex-employee’s session should have expired and did not. At that point the builder is not shipping a feature; they are debugging and coding sensitive password-reset logic under pressure, spending prompts and credits on exactly the flow that should have shipped by default. This is a documented, industry-wide pattern, not a Softr-specific talking point: research on vibe-coding failure modes names “fragile authentication and forgotten utility flows” as one of the standard ways AI-generated apps break in production.
- Login screen built
- Login screen works
- Working dashboard built
- Working dashboard works
- Password reset missing
- User forgets password, no recovery page
- Session expiry unmanaged
- Ex-employee session never expires
- OTP verification skipped
- Debugging auth under pressure
What this actually measures on a scorecard
Security & access control on this site is not a single yes/no for “does it have login.” It scores how much of that eight-item bundle ships pre-built versus how much the buyer has to code or configure from scratch, and how granular the resulting access control is once real users are in the system.
The spread across platforms this site scores is wide. Softr scores 8.5, because password, OTP, magic-link, and Google sign-in ship as toggles, user groups carry row-level restrictions down to individual buttons, and only SSO is gated to the enterprise Custom plan. Retool scores 7.5, strong on internal-facing SSO and audit logs, but its scorecard notes there are no built-in login, signup, or password-reset flows for external users; those are custom-coded. Bubble scores 6.5 on server-side privacy rules that are powerful once configured, but configuring them is entirely on the builder, and a missed rule fails silently. Further down, Lovable and Bolt both score 3.5, because their security depends on generated code and database rules the builder must write and audit themselves, with no visual way to verify what is actually exposed.
That range is the point of this guide. “Has authentication” tells you almost nothing about where a platform sits on it.
The evaluation checklist
Before you commit to a platform, check these in order:
- List which of the eight flows are pre-built, not just “supported.” Ask specifically: is password reset a page that exists today, or a feature you configure with custom code later? The difference between “native” and “possible with development work” is the difference between a toggle and a project.
- Check what plan tier gates SSO and advanced access controls. SSO in particular is routinely an enterprise-tier feature across this market. Softr’s Custom plan, Retool’s Enterprise tier, and similarly named top plans elsewhere all reserve it, so the platform that “has SSO” on its marketing page may not have it on the plan you can actually afford.
- Confirm whether access control goes below the page level. Role-based login is table stakes. What decides real security is whether restrictions reach individual records, fields, and buttons, or stop at “logged in vs not logged in.”
- Test session handling directly. Log in, then check whether you can force-expire a session, see who is currently logged in, and control session length. Client portals with turnover in external users need this; a two-person internal tool may not.
- Match the answer to the app class, not to the platform’s best-case feature list.
Why the answer depends on who is logging in
The right level of authentication is not fixed; it depends on who the app is for.
| App class | Who logs in | What actually matters |
|---|---|---|
| Internal tool, 8 teammates | Accounts you create and control | Basic login plus role checks is often enough; you can reset a forgotten password by hand |
| Client portal, hundreds of external users | Accounts you cannot manage one by one | Self-service password reset, domain or invite restrictions, and session controls stop being optional |
An 8-person internal tool can survive on password login with clean role separation, because every account holder is someone you can walk over to and help. A client portal serving hundreds of external users cannot run that way. Self-service recovery stops being a nice-to-have the moment you cannot personally reset every forgotten password, and domain-restricted or invite-only signup becomes the only realistic way to keep a public-facing app from accumulating accounts you never authorized. Scoring the same platform for both use cases without adjusting for this is the most common evaluation mistake buyers make.
Buy for the app you are actually building
The fix is not “always demand every flow.” It is to name your app’s user base honestly before you shop. A handful of trusted teammates can run on less. Hundreds of external clients cannot, and the platforms that skip password reset, OTP, and domain restriction by default will surface that gap exactly when it is most expensive to fix, after real accounts already exist. Score the platform against the flows your actual users will need, using the full breakdown at /methodology, and see Bubble vs Softr and the best client portal platforms for how this plays out for a specific app class.