If you're picking a login method for a B2B SaaS this week, start with email and password or Google sign-in, send a typed email code instead of a one-click link, and put single sign-on on the calendar before your first security questionnaire. The rest of this post explains why, using what the vendors and standards bodies document today.
Which SaaS authentication method should you ship first?
Ship the method your first 50 users can complete without help: email and password or Google sign-in for most products, with an email code as the passwordless option and enterprise SSO added when a buyer asks for it.
Searches like "saas authentication methods" and "b2b saas authentication" usually come from a founder facing exactly this trade-off, so here is the comparison I use.
| Method | Fits when | Main risk |
|---|---|---|
| Email and password | Any product, familiar fallback | Reset flow and credential reuse become your support load |
| Magic link (click to sign in) | Users on personal inboxes | A scanner or prefetch can consume a single-use link |
| Email code (OTP) | Users on managed company mailboxes | Code entry adds a step; rate-limit it |
| Google or Apple sign-in | Consumer and developer tools | Access depends on an account you don't control |
| Enterprise SSO (SAML, OIDC) | A buyer with an IT department | Needs tenant-aware data model from day one |
Most production products combine two or three of these rows. The useful question is which two fit your first users and whether your data model can add the third later without a rewrite. If you use the best SaaS MVP stack choices, this is a configuration change. If you hand-roll sessions, it is a rewrite.
What do the numbers say about passwords?
Passwords are no longer the only breach story. Verizon's 2026 Data Breach Investigations Report says 31% of breaches now start with software vulnerabilities, ahead of stolen passwords as the top way attackers get in. That is a shift from the older "most breaches start with stolen credentials" line you'll still see quoted. It doesn't make passwords safe. It means a login method is one control among several.
For the password path itself, NIST's SP 800-63B-4 is explicit. A password used as the only factor must be at least 15 characters, and at least 8 when it is part of multi-factor authentication. Verifiers must not impose composition rules and must not force periodic changes unless there's evidence of compromise. If your signup form still demands one symbol and one capital letter, that's the part to delete first.
Why do magic links fail for corporate email users?
A magic link is a single-use URL, so anything that requests the URL before the person does can use it up. Corporate mail security tools do fetch links, which is why magic links are risky for B2B users.
Microsoft's Safe Links documentation says Defender for Office 365 scans URLs before message delivery and, with rewriting on, checks them again when the recipient clicks. Some of those URLs are detonated in the background. The page doesn't say what happens to a one-time token in the process. My inference: a link that changes state on a plain GET request can be spent by a scanner, and you won't see an error in your logs because the request succeeded. Treat that as a hypothesis to test with a real managed mailbox, not a measured failure rate.
How do you make email sign-in survive scanners?
These steps work whatever library you use:
- Make the emailed URL open a page with a "Continue" button, and consume the token on the POST that button sends, not on the initial GET.
- Offer a typed code as the default for company domains, since there's nothing for a scanner to open.
- Keep tokens single-use and short-lived. OWASP's forgot password cheat sheet asks for cryptographically random tokens that are single use and expire after an appropriate period.
- Return the same response whether or not the address has an account, so the form doesn't reveal who is registered.
Defaults differ by provider, so read yours. The Auth.js email provider docs say the user has 24 hours to consume the verification token and that a database adapter is required to store it. Supabase's passwordless docs give magic links and email OTPs a one-hour default expiry and a 60-second limit between requests. Firebase supports email link sign-in, but its docs note that the shutdown of Firebase Dynamic Links on August 25, 2025 affected email link authentication for mobile apps.
Does email count as a real authenticator?
NIST says email shall not be used for out-of-band authentication, because it can be intercepted or rerouted, though confirmation codes that only verify an email address are exempt (SP 800-63B-4, section 3.1.3). For a typical SaaS that isn't a regulatory blocker. It does mean an email-only login is a convenience decision, and any product holding sensitive data should add a second factor. Callidus, the UK aesthetic-clinic SaaS I built on React and Firebase, uses native TOTP multi-factor authentication with no SMS, according to its case study.
Delivery matters too. Supabase's custom SMTP guide states that the default sender is limited to 2 messages per hour, delivers only to addresses on the project's team, and is meant for non-production use. A custom SMTP server starts with a 30-messages-per-hour limit you then raise. Wire Resend, Postmark or similar before anyone outside your team signs up. Gmail's sender guidelines require senders of more than 5,000 messages a day to Gmail accounts to set up SPF, DKIM and DMARC, so get those records in place before volume arrives.
What do passwords and OAuth still do well?
Both cost you little to ship and users already understand them. OAuth with Google or Apple removes the password from your database, and passwords work anywhere an inbox doesn't.
The OAuth security baseline is RFC 9700, published in January 2025 as BCP 240. It says public clients must use PKCE, recommends it for confidential clients, tells clients not to use the implicit grant, and requires refresh tokens for public clients to be sender-constrained or rotated. OAuth 2.1 bundles these rules, but it is still an Internet-Draft (revision 16 when I checked), not a finished RFC. Let a maintained library run the handshake; hand-rolled flows are where PKCE and state checks get missed.
What happens when the social account goes away?
Your user's access is only as stable as their Google or Apple account. If they lose it, or leave the company that issued it, they lose you too. Decide before launch how someone recovers: a verified secondary email, an admin who can re-invite them, or a password fallback behind a code. The same applies to employees who leave. A shared workspace needs an owner role that survives one person's departure, and Callidus, with six roles from super admin to receptionist, keeps every access check in role helpers so the matrix stays consistent when it changes.
For a Next.js product, Auth.js with Resend and Google covers the common signup surface, and the Next.js and Supabase auth path ships sign-in out of the box. The Auth.js specifics for multiple tenants are in Auth.js v5 for multi-tenant B2B SaaS.
BookBed, my Flutter, Firebase and Stripe booking product, uses Apple and Google sign-in, email verification and more than eighteen Resend email templates. Its users are property owners managing one to twenty units, who often sign up with a business address. That is the audience where I'd test scanner behaviour before relying on links.
When does enterprise SSO become non-negotiable?
It becomes non-negotiable when a prospect's IT team needs to provision and remove staff through their own identity provider before approving company-wide use, which typically shows up in the security review.
Buyers usually ask for SAML or OIDC, admin-run setup, SCIM provisioning and audit logs. You don't need any of it at launch, but your auth layer has to be able to grow into it. That means a tenant identifier on every user and record from the first migration. Adding tenancy after launch touches every query, which is the expensive version of this decision; the trade-offs are covered in multi-tenant SaaS architecture.
Buying SSO is cheaper than building it for most small teams. WorkOS's pricing page listed $125 per SSO connection per month for the first 15 connections on 30 September 2026, and its user-management product free up to 1M monthly active users. Check the page before you budget, since vendor pricing moves. The protocol details, SCIM and the procurement checklist live in SSO, SAML and SCIM for B2B SaaS.
If you already know your first buyer needs SSO, say so on the first call and ask which identity provider they use; that answer decides whether SAML or OIDC comes first.
Your next step: list your first 50 target users and sort them by email domain. If more than a handful sit on company-managed mailboxes, send yourself a test sign-in link through one of them this week and see whether it still works when you click.