For most new B2B SaaS products in 2026, I'd optimize for shipping quickly without painting yourself into a corner. Authentication is rarely a differentiator, but migration later can be painful.
Here's how I'd think about the options.
| Option | Best for | Lock-in | Enterprise features | Operational burden |
|---|
| Clerk | Fastest product development | Medium | Excellent | Very low |
| Supabase Auth | Supabase-centric stack | Medium | Good | Low |
| Auth.js | Full control in your app | Low | Depends on what you build | Medium |
| Ory/Kratos | Organizations with security/compliance needs and platform teams | Very low | Excellent | High |
If I were starting today
I'd generally choose:
- Small startup / MVP: Clerk
- Post-PMF B2B SaaS: Clerk or Ory
- Highly regulated enterprise SaaS: Ory
- Already all-in on Supabase: Supabase Auth
- Want maximum ownership with engineering investment: Auth.js
Clerk
The biggest advantage is that it solves the annoying parts well:
- organizations/teams
- invitations
- role management
- MFA
- passkeys
- Google/Microsoft login
- session management
- nice React components
- decent admin dashboard
For B2B SaaS, these save months.
The downside is vendor coupling. Your application tends to start depending on Clerk's:
- organization model
- user IDs
- webhooks
- SDK
- session model
You can mitigate this by:
- maintaining your own
users table
- storing Clerk ID as an external identifier
- keeping authorization in your database
- avoiding business logic inside Clerk metadata
That makes migration much easier.
Supabase Auth
Great if your stack already uses Supabase.
Pros:
- PostgreSQL-backed
- open-source core
- simple JWT model
- easy integration with RLS
Cons:
- organizations aren't as polished
- enterprise SSO isn't as mature
- you'll build more yourself
- admin tooling is lighter
I usually recommend it when someone is already committed to Supabase.
Auth.js
Auth.js is almost the opposite philosophy.
It provides authentication plumbing rather than an identity platform.
Advantages:
- almost no vendor lock-in
- own your user table
- own your sessions
- database portability
- easy to customize
Disadvantages:
you now own:
- MFA
- organization management
- invitation flow
- account recovery
- SAML
- SCIM
- audit logging
- enterprise identity integrations
Many teams underestimate how much work this becomes.
Ory / Kratos
This is the "build your own identity platform using excellent primitives."
Advantages:
- very low lock-in
- open source
- standards-first
- self-host or managed
- enterprise-ready architecture
- strong compliance story
Disadvantages:
- significantly steeper learning curve
- much more operational complexity
- documentation assumes identity knowledge
- you'll spend engineering time integrating everything
I recommend Ory when identity is considered infrastructure rather than a feature.
Vendor lock-in
People often worry about the wrong layer.
The real lock-in isn't usually authentication.
It's putting business logic into the auth provider.
A portable architecture looks like:
Auth Provider
↓
Identity (provider ID)
Your Users table
↓
Your Organizations
↓
Your Permissions
↓
Your Billing
↓
Your Roles
Avoid:
- storing roles in auth provider metadata
- storing subscription state there
- organization ownership there
- feature flags there
Treat the auth provider as an identity verifier.
Treat your database as the source of truth.
That makes switching providers much less painful.
Compliance
For SOC 2, ISO 27001, HIPAA, or enterprise procurement, what customers typically care about is:
- MFA support
- SSO (SAML/OIDC)
- SCIM provisioning (for larger enterprises)
- audit logs
- session controls
- encryption
- incident response
- documented security practices
- regional data residency (if applicable)
Those requirements are generally independent of your application's business logic.
If you anticipate enterprise customers, also consider:
- just-in-time (JIT) user provisioning
- domain verification
- organization-level authentication policies
- admin APIs
- service accounts
- fine-grained RBAC in your own application
My recommendation
If I were building a modern B2B SaaS today:
- 0–20 customers: Clerk, while keeping all authorization and business data in my own database.
- Enterprise-focused from day one (SOC 2, SAML, regulated industries): Ory if I had the engineering capacity to own identity infrastructure; otherwise, a managed provider with strong enterprise support can reduce operational burden.
- Supabase stack: Use Supabase Auth unless you know you'll need advanced enterprise identity features soon.
- If avoiding vendor lock-in is your top priority: Auth.js or Ory, recognizing that you're trading lower lock-in for substantially more engineering effort.
The architecture matters more than the provider. If your application owns users, organizations, permissions, billing, and authorization, and the auth provider only establishes identity, migrating later is usually a manageable project rather than a rewrite.
