Auth is the decision founders spend the least time on and regret the most. The right choice is almost never determined by API ergonomics, it is determined by whether you sell to individuals or to organizations, and whether enterprise SSO shows up in month three or month thirty. Pick by requirement, not by whichever provider had the nicest landing page the week you started.
Start with the question that actually decides it
Are your accounts owned by people, or by companies? That is the fork. A B2C product has one user, one account, one billing relationship, and the whole model fits in a users table. A B2B product has an organization that owns the subscription, members who belong to it, roles that decide what each member can do, invitations for members who do not exist yet, and the reality that one human belongs to several organizations and needs to switch between them.
Retrofitting the second shape onto the first is a rewrite, not a feature. Every foreign key pointing at a user ID has to point at an organization ID instead. Every check that asked "is this row mine" has to ask "is this row inside an org I belong to, and does my role there allow this." Billing moves up a level. That work touches nearly every query, and it lands exactly when you are trying to close your first real customers.
The second fork is nearly as consequential: will you need SAML or SCIM within twelve months? Founders reflexively say no, and most B2B founders are wrong. Single sign-on and directory provisioning are what a customer's IT department asks for the moment a product passes a handful of seats, and the request arrives as a contract blocker rather than a backlog item. If any company with an IT department might buy your product, plan for it now even if you do not build it now.
What auth actually includes
The parts everyone remembers
Sign up, sign in, password reset, social login with Google and GitHub, sessions that survive a page reload. Every tutorial covers this and every demo shows it, and it is genuinely the easy part. Any option below handles it in an afternoon.
The parts that bite later
Email verification, and what a half-verified account can do in the meantime. Account linking, when someone signs up with a password and later clicks "Sign in with Google" using the same address. Session revocation, so a password change or a fired employee actually logs someone out everywhere instead of leaving a valid cookie in the wild. Support impersonation, so you can see what a confused customer sees. Audit logs, because the first enterprise security questionnaire asks for them. And the deletion path, where a user asks to be erased and their identity turns out to be tangled in billing records you must keep.
This second list is where hand-rolled and agent-generated auth quietly fails, because none of it shows up in a demo. A login form that works looks identical to one that works and revokes sessions correctly. The gap becomes visible during an incident, a compliance review, or a support escalation.
The options, by what they are actually good at
Managed identity platforms (Clerk, WorkOS)
Clerk and WorkOS sell the hard part. Organizations, invitations, role assignment, and enterprise SSO are shipped products with admin surfaces and support, not projects you scope. WorkOS exists because SAML and SCIM are miserable to implement against the long tail of identity providers, and it turns that into a configuration screen. Clerk covers similar ground with more emphasis on drop-in components. If you are B2B from day one, this category buys back weeks.
The cost is structural. Pricing here is usage-based per monthly active user, so your auth bill grows with your success whether or not those users pay you. You take a hosted dependency in your signup path: if the provider has a bad day, nobody logs in. And your user records live in their system, so joining users to the rest of your product means syncing identities into your own database or living with an ID you cannot join against.
Framework-native (Auth.js, Better Auth, Lucia)
This category runs inside your application. Auth.js is the incumbent, Better Auth is the more recent and more opinionated take with plugins for organizations and two-factor, and Lucia sits lowest, closer to primitives than a framework. All are free and open source, you host them, and sessions live in your own database next to everything else. That last property is underrated: joining a session, a user, and a subscription is just a query.
The cost is that you own every edge case in the list above. Better Auth narrows the gap with its org and SSO plugins, which is why it is the sharpest comparison against the hosted platforms; read Better Auth versus Clerk before committing either way. This is the option most improved by a good boilerplate and most punished by a bad one. A kit that already wired verification, revocation, and role checks is a real head start. A kit that scaffolded a login page and stopped is a maintenance burden dressed as a feature.
Bundled with your database (Supabase Auth)
Supabase Auth ships as part of the database platform, which is its whole argument. One vendor, one dashboard, one bill. More importantly, the authenticated user ID is visible inside Postgres, so row-level security policies reference it directly and your isolation rules live next to your data instead of in application middleware. For B2C, that combination is hard to beat on speed.
The cost is coupling. Choosing Supabase Auth largely means choosing Supabase as your database, and unwinding one later means unwinding both. There is also a ceiling: organizations, granular roles, and enterprise SSO sit further from the core product here, so B2B products end up building that layer themselves.
Rolling your own
There are real reasons to build auth yourself: a regulatory requirement that credentials never leave specific hardware or a jurisdiction, an existing corporate identity system you must integrate with rather than replace, or a non-standard factor specific to your industry. They share a shape: an external constraint makes every off-the-shelf option unusable.
"The agent can write it" is not on that list. Auth failures are adversarial rather than functional. Ordinary bugs are found by users doing normal things and reported quickly. Auth bugs are found by people looking for them, and the report arrives as a breach. Generated code optimizes for the path you described, and nobody describes the attack.
What changes when an agent writes the code
Auth is the worst place for unreviewed generated code, because the failure mode is silent. A missing authorization check produces no error, no warning, no complaint. It produces a working feature with a hole in it.
The patterns are consistent enough to name. Client-side gating without a server-side check, where the button is hidden but the endpoint behind it answers anyone. Session checks present on every route written in week one and absent from the route added in week four. And permission logic inlined per handler instead of centralized, so a rule change has to be found in eleven places and gets fixed in nine.
The mitigation is structural. Have exactly one auth helper, make it the only supported way to get the current user and their permissions, call it in every server-side entry point, and write that rule where the agent will read it. A brief saying "all authorization goes through requireUser and requireRole in lib/auth, never inline" prevents more holes than any amount of later review. Our AGENTS.md templates include constraints in that form, and the AGENTS.md generator produces a starting file from your project so the rule exists before the first generated route does.
The multi-tenancy question hiding inside auth
"Who is logged in" and "which tenant's data can they see" are separate problems, and conflating them is how data leaks between customers. Authentication ends the moment you know the identity of the caller. Everything after is authorization, and in B2B the dominant question is not about roles at all, it is tenancy: does this row belong to an organization this person is a member of?
Enforce that at the data layer, not the route layer. A check in a route handler protects that route. A check embedded in how data is fetched, through row-level security or a repository layer where every query is scoped by construction, protects every route including the ones that do not exist yet. Route checks fail open when forgotten. Data-layer enforcement fails closed. The SaaS database decision guide covers where that enforcement lives and how the tenancy models compare.
How to evaluate what a boilerplate ships
The checklist is short. Is authorization enforced on the server, or only reflected in the UI? Is there a single helper every protected path goes through, or is the check copy-pasted? Are roles and organizations in the schema, or is there a user table with an is_admin boolean that will not survive a real customer? Is there a test asserting a permission boundary, one that proves user A is rejected when reaching for user B's record?
The fastest practical test takes five minutes. Point your coding agent at the kit and ask how the codebase prevents user A from reading user B's records. A well-structured kit produces a specific answer naming a helper, a policy, or a scoped query. A poor one produces a confident paragraph about middleware that turns out to describe two of the nine routes. That specificity is a good proxy for the quality of the whole codebase.
If you want a shortlist rather than a method, the Agent-Ready category collects kits scored on this kind of structure, the agent-ready boilerplate checklist explains the broader frame, and the best auth for Next.js roundup narrows to providers with real integration support.
The migration cost, stated honestly
Not all auth switches hurt equally, and the ranking tells you where to overshoot. Adding email and password to a social-only setup is easy: new credentials, no data migration. Moving from individual accounts to organization accounts is hard, and it gets harder every month because the number of tables pointing at a user ID only grows. Swapping providers while holding existing password hashes is hardest, because hash formats differ and you cannot recover plaintext, so you either negotiate a bulk import or run both systems in parallel and rehash users as they log in.
That asymmetry is the argument for overshooting on the B2B side. Modeling organizations you do not need yet costs a few days. Adding them after eighteen months of B2C assumptions costs a quarter. If there is any realistic chance you sell to companies, model the organization now, even if every organization has one member for the first year.
Frequently Asked Questions
What is the best auth provider for a new SaaS in 2026?
There is no single answer, but there is a clean rule. If you sell to organizations, start with a managed identity platform like Clerk or WorkOS, because organizations, invitations, roles, and SSO are the expensive parts and those platforms sell them finished. If you sell to individuals, use something framework-native like Auth.js or Better Auth, or the auth bundled with your database like Supabase Auth, and keep sessions where they are cheap to join against. The tipping point is the first time a prospect asks who administers their team's accounts: past that question you are a B2B product, whatever your marketing says.
Can I let Claude Code build my auth from scratch?
No for the authorization layer, qualified yes for the wiring. Generating integration code around an established provider is a good use of an agent: the patterns are well represented and mistakes tend to be loud. Generating the authorization layer itself, the logic deciding who may read and write what, is a bad use, because those failures are silent and only an attacker finds them. The practical split is to let the agent wire the provider and write the routes while you define the permission model, own the single auth helper, and write the tests that assert a boundary holds.
When do I actually need SSO and SCIM?
At the first enterprise deal, which arrives earlier than founders expect and always as a contract blocker rather than a roadmap item. The cheap way to be ready is not building SAML in advance, it is structuring identity so SSO can be added without a rewrite: model organizations from the start, treat login method as a property of the organization rather than the user, avoid assuming every account has a password, and pick a provider that offers SSO as a configuration change. Then the enterprise request costs a week instead of a quarter.
Is Supabase Auth enough for a real product?
Yes for B2C, and yes for simple B2B where a team is a few people with identical permissions. Its real advantage is that the authenticated identity is visible inside Postgres, so row-level security enforces isolation at the data layer rather than in application code, which is the correct place for it. It stops being enough when you need real organization management: multiple orgs per user with switching, delegated invitations, granular roles, and SAML with directory provisioning. At that point you are building an identity product inside your product, and buying it starts to look cheap.
How do I check whether a boilerplate's auth is any good?
Use the permission-boundary test. Ask how the kit stops user A from reading user B's records, then verify the answer in the files rather than trusting it. You want enforcement in one place that every path goes through, roles and organizations present in the schema rather than bolted on, server-side checks that do not depend on the UI hiding anything, and at least one test that fails when the boundary is removed. If you would rather start from a filtered list than audit kits yourself, the Agent-Ready category already scores boilerplates on exactly this.
