“Which auth should I use?” is the first serious question most SaaS founders ask when MVP auth stops working. The three names that come up: Auth0, Firebase, Supabase. Each solves a different slice of the problem — and each has a clear sweet spot. Here’s the honest take, and a fourth option that fits the gap most teams actually land in.
Auth0: built for enterprise, priced for enterprise
Auth0 is the grown-up answer. Deep feature set (rules engine, actions, rich SAML/SCIM), strong compliance story, used by companies with dedicated security teams.
The catch: its per-MAU pricing punishes B2B SaaS. A customer with 500 employees using your tool means 500 MAU × their rate — while the customer pays you one flat subscription. Founders regularly find that Auth0’s bill becomes their third-largest vendor cost somewhere between 1k and 10k users.
Sweet spot: Series B+ with budget for $1-5K/month on auth alone.
Firebase Auth: fast to start, hard to leave
Firebase is the quickest way to ship a prototype. Drop the SDK, click a few console buttons, ship. For a weekend project or an MVP that will stay within Google’s ecosystem, it’s unbeatable.
The catch: multi-tenancy is a premium feature, custom claims are capped at 1KB, SAML is paid-only, SCIM isn’t really supported, and migrating users out is painful (Firebase’s password hash format is hard to port to anywhere else). Great on-ramp, bad long-term home for anything B2B.
Sweet spot: prototypes and consumer apps staying inside Firebase forever.
Supabase Auth: great if you’re already on Supabase
If you’re building on Supabase (Postgres + APIs + real-time), auth integrates deeply. Row-level security reads the JWT directly, SDKs are unified with the rest of the stack, and the pricing is generous.
The catch: if you’re not on Supabase, the auth alone isn’t a compelling reason to migrate. SAML is spartan, SCIM isn’t native, and multi-tenancy is whatever you build in Postgres yourself.
Sweet spot: teams already committed to Supabase.
The gap most dev-first SaaS lands in
Look at the ICP for the three above:
- Series B enterprise SaaS (Auth0)
- Firebase-locked consumer apps
- Supabase users
That leaves the largest group in the middle: pre-revenue through Series A B2B SaaS, dev-first, building something that needs to scale into enterprise without paying enterprise prices on day one.
Why we built LoginWith
That gap is exactly why LoginWith exists. The positioning:
- Two-tag SSO — one script, one
<a href>. No backend, no client secret, no OAuth app registration. Ship sign-in in minutes. - Flat-rate pricing — $99/mo platform fee + $0.02 per managed user (2k included on Growth). No MAU billing. Active users aren’t taxed.
- Branded hosted login page at
{yourslug}.loginwith.pagefor free. Custom domains on paid tiers. Full PKCE, JWKS, session management, all handled. - SAML and SCIM as a paid add-on priced per enterprise customer — $199-300/mo per connection. You only pay when a deal depends on it.
- SSO-ready architecture from day one — tenant-aware, auth-provider aware. Your first enterprise deal is a two-week integration, not a two-quarter rewrite.
The decision
- Series B+ enterprise SaaS → Auth0 (negotiate)
- Weekend prototypes / Firebase-ecosystem apps → Firebase Auth
- Already on Supabase → Supabase Auth
- Dev-first B2B SaaS from pre-revenue to Series A → LoginWith
For most readers of this post, that last row is where you are.