OAuth vs Magic Link for SaaS: Which Login Should You Build?

You’ve decided to skip passwords — good call, nobody wants to manage password resets and breach liability for an MVP. Now the choice is OAuth vs magic link for how users actually sign in. Both are passwordless, both are popular, and they have genuinely different tradeoffs around conversion, security, deliverability, and how much you have to build. This post breaks down when each one wins for an indie SaaS, with implementation notes and a recommendation.

What each flow actually is

OAuth (social login — “Sign in with Google/GitHub/Apple”) delegates authentication to a provider the user already trusts. The user clicks a button, gets redirected to Google, approves, and comes back with a verified identity. You never see a password; the provider vouches for them.

Magic link authenticates via a one-time URL sent to the user’s email. They enter their email, you send a link containing a signed, single-use, time-limited token, they click it, and they’re logged in. The assumption: whoever controls the inbox is the legitimate account owner.

Both remove passwords. The difference is who verifies the user — a third-party identity provider (OAuth) or their email inbox (magic link).

Conversion and UX

This is usually the deciding factor for indie SaaS, where every signup matters.

Magic links remove almost all friction at signup: type an email, click a button, no password to invent. That simplicity can lift conversion meaningfully on first signup. The hidden cost is the context switch — the user has to leave your app, open their email, find your message, and click. If the email is slow, lands in spam, or they’re on a desktop with email on their phone, the flow stalls. Magic links shine for low-frequency logins (monthly dashboards, billing portals) and feel tedious for anything you log into daily.

OAuth is often the fastest path for users who have an account with the provider: two clicks, no typing, no inbox detour. But it adds a tiny bit of cognitive load (“which account did I use?”) and only helps users who have and trust that provider. Developers love “Sign in with GitHub”; your grandmother does not have a GitHub account.

Deliverability is a real risk for magic links

A magic link is only as reliable as your email delivery. If the email lands in spam or arrives 90 seconds late, login fails and the user bounces. This means committing to proper email infrastructure: a reputable sending provider (Resend, Postmark, SES), correct SPF/DKIM/DMARC records, and a warmed sending domain. For an indie hacker, that’s real setup work, and deliverability problems are frustrating to debug because they’re intermittent and inbox-dependent.

OAuth has no such dependency — the redirect either works or it doesn’t, and there’s no inbox in the path.

Security tradeoffs

Neither is automatically “secure” — implementation decides it.

Magic link risks: the security reduces to “whoever can open that email can sign in.” If a user’s inbox is compromised, so is your app. Links forwarded, logged in proxies, or scanned by aggressive email security bots (which sometimes pre-click links and consume the one-time token) are real failure modes. Mitigate with single-use tokens, short expiry (10–15 minutes), and binding the link to the requesting session/device where possible.

OAuth risks: you inherit the provider’s security, which is generally excellent, but you also inherit account-recovery edge cases and provider outages. A misconfigured redirect_uri or unverified state parameter opens you to CSRF and token interception, so the standard checks are mandatory.

For most indie SaaS, both are “good enough” security-wise when implemented correctly. Neither meets the bar for high-compliance environments on its own — that’s where you’d add passkeys or MFA.

Implementation effort

Magic link is conceptually simple but operationally involved. You generate and store a token, send an email, verify on click, and create a session:

// Request a magic link
const token = crypto.randomUUID();
await db.magicTokens.create({
  token,
  email,
  expiresAt: addMinutes(new Date(), 15),
  used: false,
});
await sendEmail(email, `Sign in: ${origin}/auth/verify?token=${token}`);

// Verify on click
const record = await db.magicTokens.findUnique({ where: { token } });
if (!record || record.used || record.expiresAt < new Date()) {
  return new Response('Invalid or expired link', { status: 400 });
}
await db.magicTokens.update({ where: { token }, data: { used: true } });
await createSession(record.email); // log them in

Plus the email infrastructure above. The crypto is easy; the deliverability is the work.

OAuth has trickier protocol details — the authorization code flow, state for CSRF, token exchange, fetching the user profile — but a library (Auth.js, Passport, Better Auth) handles most of it. You’ll register an OAuth app with each provider and manage client IDs/secrets and callback URLs. More providers means more app registrations to maintain. Hosted providers like Clerk remove most of this work if you’re in the React ecosystem — our Clerk alternative comparison covers when that’s worth it and when it isn’t.

---

Skip the build entirely. Beag gives micro-SaaS authentication out of the box — login flows wired up — alongside Stripe payments. No email deliverability tuning, no OAuth callback debugging. Ship the product.

---

The recommendation

For most indie SaaS, the strongest setup is offer both, not pick one:

• OAuth (Google, plus GitHub if you’re developer-facing) as the primary, fastest path. It’s the lowest-friction option for users who have the account, with no deliverability risk.
• Magic link as the fallback for users who don’t want to use social login or don’t have the relevant provider.

This “layered passwordless” approach is what mature systems do — it improves resilience and avoids lockouts when one method fails. If you must ship only one to start:

• B2B / developer tools → lead with OAuth (your users have Google Workspace and GitHub).
• B2C / low-login-frequency products → magic link is fine and lowest-friction at signup, provided you nail deliverability.

Whatever you choose, the session you create afterward is its own decision — see our JWT vs session auth guide for how to keep users logged in once they’re through the door.

Wrapping up

OAuth delegates trust to a provider — fast, no deliverability risk, best for audiences that already have Google/GitHub accounts. Magic links remove signup friction and need no provider, but they live or die on email deliverability and inbox security. For most indie SaaS, offer OAuth as the primary path and magic link as the fallback rather than betting everything on one.

Don’t want to build login flows at all? Beag adds authentication and Stripe payments to your MVP in minutes →