Authentication is one of those decisions that feels small at project start and turns into a 40-tab rabbit hole by week three. Every SaaS has to solve it. Log in, stay logged in, recover access when something breaks. The surface area looks narrow. Then you add multi-tenancy, invite flows, enterprise requirements, and your "simple" auth module starts touching half the codebase.
I've built auth into three production products: BookBed (Flutter + Firebase, Apple and Google Sign-In plus email verification and 18+ transactional Resend templates), Callidus (React + Firebase), and Pizzeria Bestek (React + Supabase). The decisions looked different in each case because the users looked different. Here's the framework I've landed on for B2B SaaS auth in 2026.
Why does your auth method decide more than you think?
Your auth method shapes conversion, support volume, and enterprise deal probability — before a single product feature ships.
That's not abstract. According to Postmark's guide on passwordless authentication, 50% of all support tickets in password-based systems are password-related. Fifty percent. Half your support queue handling "I forgot my password" before anyone raises a real product question. The same guide notes that 81% of corporate data breaches originate from compromised credentials — which explains why the industry has been steadily moving toward passwordless.
But passwords are still the default, and for a reason. They're predictable. They don't require email deliverability infrastructure to function at login time. For products serving less technically-savvy users, the familiar email-and-password form still converts reliably because users know the mental model.
The auth decision is also a positioning decision. If you're selling to companies with IT departments, your auth story becomes part of the procurement conversation. "We support SSO" is a deal-maker. "We don't support SSO yet" is increasingly a reason to defer, especially for accounts above 50 employees.
The cost of choosing wrong isn't only technical debt. It shows up in the support tickets that pile up in week one, in the enterprise deal that stalls at security review because SSO isn't available, in the user who bounced at the login screen because the magic link didn't arrive. Authentication failure is usually silent from the application's perspective — no 500 error, no alert — which makes it easy to overlook until the data shows it.
Passwords, magic links, OAuth, enterprise SSO. Most production SaaS products use at least two. The question is which combination fits where you are right now — and whether your architecture can add the others without a full rewrite.
The deliverability trap that no magic link tutorial mentions
Corporate email security scanners auto-click every link in every email, consuming your magic link token before the user ever sees the inbox.
Scalekit's comparison of passwordless methods documents this as a known failure mode specific to enterprise and corporate email environments. Proofpoint, Mimecast, and Microsoft Defender for Office 365 all follow links in received emails by default as a malware-scanning step. Your backend marks the token as used. The user opens their inbox, the email looks fine, they click the link, they get an error page.
Here's what that failure looks like from the user side: A new signup using a corporate email address. They request a magic link. The email arrives. They click. Expired. No error in your application logs. No failed request. Your "send email" call returned 200. The problem is invisible on your end and opaque to the user. They email support. They churn.
OTP codes survive this. Magic link tokens don't. OTPs are a string the user types — there's nothing for a scanner to pre-consume. For consumer SaaS where users sign up with personal Gmail addresses, magic links work well. For B2B products where the target user is an employee under a corporate email security policy, magic links become a real support liability.
On the deliverability foundations: SPF, DKIM, and DMARC records need correct configuration before auth emails reach any inbox reliably. Gmail and Outlook have been enforcing DMARC-passing sender domains more aggressively since the 2024 bulk-sender policy changes. A missing DMARC record won't necessarily break delivery in development, but it will in production at scale. If you're building on Supabase, the default email sender is throttled at a rate that's fine for local testing and silently broken at real signup volumes. Wire a production provider — Resend, Postmark, or SendGrid — before you open public registration. Not after the first week of signups stall.
OAuth and social login: fast to ship, one dependency to understand
Google and Apple Sign-In remove credential management entirely. The user authenticates with an identity they already maintain. Login conversion goes up. Password reset tickets disappear.
Actually — that only holds for products where users sign up with personal accounts. For B2B tools where employees use company-managed Microsoft Entra or Okta, social login is often irrelevant, occasionally the wrong choice entirely.
Worth building in from day one regardless. The dependency to understand: your user's access to your product is exactly as stable as their Google or Apple account. If they lose that account, they lose access to you too. Design your account recovery flow with this in mind before you're debugging it at midnight.
OAuth 2.1 is the 2025-finalized baseline spec: PKCE mandatory for all clients — not just public clients as it was in OAuth 2.0 — implicit grant fully removed, refresh token rotation built in. If you're writing custom OAuth flows rather than delegating to a library, these aren't optional upgrades. They're the current standard.
When does enterprise SSO become non-negotiable for B2B SaaS?
Enterprise SSO becomes non-negotiable when a prospect's IT team must provision users through their existing identity provider before approving company-wide use.
This isn't a feature request that emerges from user feedback. It's a procurement gate. "Does it support SSO?" shows up in vendor evaluation questionnaires before most product demos happen. The answer determines whether the deal advances or stalls at the IT security review stage.
WorkOS's guide to enterprise SSO for B2B SaaS lays out what IT security teams actually require: support for both SAML 2.0 and OIDC (enterprise identity providers use both, depending on the IdP), self-serve SSO configuration so the customer's admin can wire up their own connection without involving your engineers, SCIM directory sync for automated user provisioning and deprovisioning, and audit logs for compliance review. WorkOS notes that companies including OpenAI, Anthropic, Cursor, Perplexity, Vercel, and Replit all run enterprise identity on WorkOS — these are all developer-platform businesses where identity management is a genuine procurement requirement, not a nice-to-have.
Pricing structure matters here. Auth0 and Clerk charge by monthly active user, which scales badly as enterprise tenants grow large. WorkOS charges per SSO connection, scaling with your enterprise customer count instead of your user count. For B2B SaaS where a single account might have hundreds of users, the per-connection model is a meaningfully better fit.
Most SaaS MVP builds don't need enterprise SSO at launch. They need it before the first enterprise deal closes. The implication: pick an auth provider that can add SSO without requiring a rewrite of your auth layer. If your launch-day auth choice can't grow to SSO without structural rework, you're accumulating technical debt against a predictable future requirement.
What does an Auth.js stack actually look like?
Auth.js with Resend for email and Google OAuth for social login covers most of the signup surface for consumer and dev-tool SaaS — no password system required.
The best SaaS MVP stack for Next.js auth: Auth.js (formerly NextAuth) or better-auth, with Resend as the email provider. Auth.js has a direct Resend integration in its official docs. Point it at a Resend API key, configure the email template, set maxAge: 3600 on the verification token (one hour is the standard expiry per Postmark's guidance), and magic links are live. Add Google OAuth in the same session. Between the two, you cover the signup surface for most consumer and developer-facing products without building a password system at all.
The Next.js + Supabase auth path ships auth out of the box — OTP-based magic links and social login both work — but the default sender needs replacing before real users sign up. Same Resend/Postmark swap, same configuration, same deadline: before public launch.
Better-auth emerged as a TypeScript-first alternative to NextAuth — framework-agnostic, cleaner API surface, more opinionated defaults. Both are production-viable in 2026. The practical choice: do you want the library to make decisions for you (better-auth) or do you want maximum configurability (Auth.js)?
For BookBed, the stack is Firebase Auth: Apple Sign-In and Google Sign-In handled natively, plus email/password with verification, and Resend wired for 18+ transactional email templates — confirmations, trial expiry, notification preferences. Firebase Auth doesn't do magic links in the click-once sense, but email OTP verification covers the same authentication surface. OTP also survives corporate email scanners, which matters as BookBed targets property managers who often use business email accounts.
Which approach should you actually ship first?
Match your auth approach to your first 50 users — not the enterprise deal you're planning to close in year two.
| Approach | When to use | Watch out for | |---|---|---| | Email/password | Any product, familiar fallback | Resets drive support volume | | Magic links | Consumer SaaS, personal email users | Corporate scanner problem; configure SMTP before launch | | Google/Apple OAuth | Developer tools, consumer products | User's account health is outside your control | | Enterprise SSO | B2B selling to 50+ employee companies | Significant investment — build or buy decision |
Design for multi-tenancy from the start, even if you ship only Google OAuth at launch. Adding enterprise SSO to a single-tenant auth architecture later means structural rework, not an addition. That debt arrives faster than expected once the first enterprise sales conversation starts.
The question to answer before you pick anything: who exactly are your first 50 users, and do they use personal email or company-managed email? If it's corporate Outlook across the board, magic links are already off the table. If it's personal Gmail and GitHub, magic links plus Google OAuth covers almost everything.
Auth is infrastructure. It doesn't ship features. But it's the first thing every new user touches and the first gate enterprise IT opens in procurement. Get it right for the stage you're in — then revisit when the next stage arrives.