I use both magic link and Google OAuth in my SaaS apps. After running both for a while, I have opinions on when each one makes sense.

The short answer: offer both. They serve different users.

Why Not Just Use Passwords?

I don’t use passwords in any of my apps. Here’s why.

For users: most people don’t use password managers. They reuse the same password across sites, or they pick something weak and forget it within a week. Then they hit “Forgot password,” which sends them an email with a reset link — which is just a magic link with extra steps.

For you as the developer: passwords mean salting, hashing (bcrypt or argon2), storing hashes securely, building a reset flow, handling timing attacks on comparison, rate-limiting login attempts, and dealing with credential stuffing from leaked databases. That’s a lot of work for something users don’t even want to deal with.

Magic links give you the same email-based identity without the baggage.

The Basics

Magic links: user enters email, gets a link with a one-time token, clicks it, they’re in. No password. The implementation is straightforward — generate a token, hash it, store it with a 15-minute expiry, email the link, verify on click, delete the token.

Google OAuth: user clicks “Sign in with Google,” authenticates on Google’s side, gets redirected back. You get their email, name, and avatar. Also no password. It’s easy to implement — Google handles the credential verification, so there’s no password hashing or token storage on your side. You still need a database for users and sessions, but the auth check itself is Google’s problem.

Both methods verify email access by design — magic links because the user has to click a link in their inbox, Google because the account has a verified email.1 With password login, you don’t get this for free, so you end up building a separate email verification flow.

Both are simple enough that a coding agent can generate either implementation in a few minutes.

What I’ve Seen in Practice

Most users — I’d estimate 60-70% — pick Google Login when both options are available. One click, no context switching. Done.

The rest use magic links. Some don’t have Google accounts. Some are on work devices where IT restricts which apps can use Google OAuth. Some just don’t want Google knowing which apps they use.

Nobody complains about magic links. The “check your email” step is normal now — Slack, Notion, and plenty of others have trained people on this flow.

The one support issue I get: magic link emails landing in spam. More on that below.

The magic link flow on mobile: enter email in the browser, switch to the mail app, wait for the email to arrive, tap the link, get bounced back to the browser. It works, but it’s clunky. Every app switch is a chance for the user to get distracted or give up.

Google Login on mobile is smoother — you might see an account chooser or consent screen, but there’s no app switching. The whole flow stays in the browser.

If your app has significant mobile traffic, Google Login matters more.

The Email Deliverability Problem

If you’re sending transactional email from a fresh domain, your emails might hit spam folders. Gmail is aggressive about this. Even with SPF, DKIM, and DMARC configured correctly, a new domain has no reputation.

I use Postmark for transactional email. My magic link emails are plain text with a single link.

What helps:

  • Use a reputable transactional email service — Postmark, Resend, AWS SES. Don’t send from your own server.
  • SPF, DKIM, and DMARC are table stakes. Without them, you’re more likely to end up in spam.
  • Keep the email minimal — plain text or simple HTML. It’s not that rich HTML is inherently spammy, but simpler emails tend to do better when your domain reputation is still building.
  • Send from a subdomain — e.g. use mail.myapp.com as the sending domain, so your transactional reputation is separate from your marketing reputation.

Google Login sidesteps all of this. No emails to send, no deliverability to worry about.

Despite the mobile friction and email headaches, magic links cover users that Google Login can’t reach.

Google Workspace admins can restrict which apps their users OAuth into. Magic links only need email delivery, not OAuth approval. If you’re targeting teams or enterprise users, this matters.

Magic links don’t depend on a federated identity provider. No Google Cloud Console setup, no client ID rotation, no worrying about Google changing their OAuth policies. You still depend on email infrastructure — an ESP, DNS records, the recipient’s mailbox provider — but that’s infrastructure you control and can switch out.

And they work with any email provider — Gmail, Outlook, ProtonMail, custom domains.

Linking Accounts

On the backend, both methods resolve to the same user by email. Someone signs up with Google, later tries a magic link with the same email — same account. I store which auth method was used, but identity is email-based.

Google recommends using the stable sub claim from the ID token as the primary identifier, not the email, because emails can change. I still match on email for account linking, but I store the Google sub as well.

Security Gotchas

Both methods eliminate passwords, which eliminates credential stuffing — the most common attack vector for web apps. But each has its own pitfalls.

For magic links: hash the token before storing it, keep the expiry short (15 minutes), make tokens single-use, and rate-limit the send endpoint so nobody can flood a user’s inbox.

For Google OAuth: verify the id_token signature and check aud, iss, and exp. Validate the CSRF state parameter. Check email_verified before trusting the email — and if you’re restricting to Workspace accounts, check hd too.

What I’d Do

Offer both. Put Google Login up top — it’s what most users will pick. Magic link below it for everyone else.

If you can only build one first, start with magic links. They work for anyone with an email address and don’t tie you to a specific identity provider. Add Google Login when you want to reduce signup friction.

  1. One caveat: Google’s email_verified flag is authoritative for @gmail.com and Workspace accounts. For third-party email addresses linked to a Google Account, ownership could have changed since the account was created. For most SaaS apps this is a non-issue, but worth knowing if you’re auto-linking accounts by email. ↩