The thesis: 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 organizations, and whether enterprise SSO shows up in month three or month thirty. This guide picks by requirement, not by popularity.
Start with the question that actually decides it
- Frame the real fork: B2C individual accounts versus B2B organization accounts. Everything else follows from it.
- Argue that adding organizations, roles, and invites to an auth system built for individuals is a rewrite, not a feature.
- Give the second fork: will you need SAML or SCIM within twelve months, and be honest that most B2B products will.
What auth actually includes
The parts everyone remembers
- Sign up, sign in, password reset, social login, sessions.
The parts that bite later
- Email verification, account linking, session revocation, impersonation for support, audit logs, and the deletion path.
- Argue this second list is where hand-rolled and agent-generated auth quietly fails, because none of it shows up in a demo.
The options, by what they are actually good at
Managed identity platforms (Clerk, WorkOS)
- Strength: organizations, invites, roles, and SSO as products rather than projects. Best fit for B2B from day one.
- Cost: per-active-user pricing that scales with success, plus a hosted dependency in your signup path.
Framework-native (Auth.js and equivalents)
- Strength: free, self-hosted, full control, sessions in your own database.
- Cost: you own every edge case, and the org and SSO layer is yours to build. Argue this is the option most improved by a good boilerplate and most punished by a bad one.
Bundled with your database (Supabase Auth and similar)
- Strength: one vendor, row-level security integrates naturally, cheap at small scale.
- Cost: coupling auth to database choice, and a ceiling on B2B features.
Rolling your own
- Argue this is defensible only for unusual requirements, and name what those actually are.
- State plainly that "the agent can write it" is not one of them, and say why.
What changes when an agent writes the code
- Argue auth is the worst place for generated code because failures are silent and adversarial rather than functional.
- Name the specific patterns agents get wrong: missing server-side authorization checks behind client-side gating, session checks skipped on new routes, and permission logic duplicated instead of centralized.
- Give the mitigation: one auth helper, called everywhere, documented in the agent brief. Link /templates/agents-md and /free-tools/agents-md-generator.
The multi-tenancy question hiding inside auth
- Explain that "who is logged in" and "which tenant's data can they see" are separate problems that get conflated.
- Argue tenancy should be enforced at the data layer, not the route layer, so a forgotten check fails closed.
- Cross-reference /blog/saas-database-decision-guide for where that enforcement lives.
How to evaluate what a boilerplate ships
- Give the checklist: is authorization server-side, is there one helper, are roles and orgs modeled, is there a test around a permission boundary.
- Argue the fastest test is asking your coding agent to explain how the kit blocks user A from reading user B's records, and judging the specificity of the answer.
- Point at /categories/Agent-Ready and /blog/ai-agent-ready-boilerplate-checklist for the broader evaluation frame.
The migration cost, stated honestly
- Rank the switches by pain: social-only to email-plus-password is easy, individual to organization accounts is hard, provider swap with existing password hashes is hardest.
- Argue this asymmetry is the reason to overshoot slightly on the B2B side if there is any chance you sell to companies.
Frequently Asked Questions
What is the best auth provider for a new SaaS in 2026?
- Answer conditionally: managed platform for B2B, framework-native or database-bundled for B2C, and explain the tipping point.
Can I let Claude Code build my auth from scratch?
- Answer no for the authorization layer, qualified yes for wiring an existing provider, and explain the difference.
When do I actually need SSO and SCIM?
- Answer: the first enterprise deal, which arrives earlier than founders expect, and describe the cheap way to be ready.
Is Supabase Auth enough for a real product?
- Answer yes for B2C and simple B2B, and name the point at which the org and SSO gap forces a move.
How do I check whether a boilerplate's auth is any good?
- Answer with the permission-boundary test and point at /categories/Agent-Ready for kits already scored.
