“Should we use OAuth or magic links?” is a question that lands in our inbox at least once a month. The honest answer is both, for different users, but the more useful answer is to understand the trade-offs first.
What each one actually is
OAuth (specifically, “Sign in with Google / GitHub / Microsoft”)
delegates identity to a provider the user already trusts. Your app never
sees a password; the provider hands you back a signed assertion that
“this user is priya@example.com and we vouch for it.”
Magic links keep identity local. The user types their email, you generate a single-use token, you email a link containing it, and clicking the link signs the user in.
Both eliminate the password from your database. Past that, they have almost nothing in common.
Where OAuth wins
- Sign-up friction: a single click can sign up and sign in the same user. No password to invent, no inbox to check.
- Implicit MFA: if the upstream provider enforces MFA (and Google Workspace usually does), you inherit that posture for free.
- Org context: Google Workspace and Microsoft Entra return the user’s domain, which is exactly the signal you need to auto-route them into a team workspace.
Where magic links win
- No provider lock-in for the user: the user doesn’t need a Google account, a GitHub account, or anything at all besides an email.
- Cleaner downgrade: when a user changes jobs and their Google identity disappears, a magic link to their new email still works.
- Lower implementation cost: no PKCE, no client secrets, no redirect-URL allowlists, no per-provider rotation of credentials.
Where each one quietly hurts
OAuth’s hidden tax is the provider outage. When Google’s auth endpoint is degraded, your “sign in with Google” button takes 30 seconds to fail. You don’t get a notification; your users just churn. We’ve watched a real-money chunk of trial signups disappear during a 20-minute upstream blip.
Magic links’ hidden tax is the email pipeline. Spam folders, corporate gateways that “click protect” links (which burns your single-use token), and aggressive rate limits on transactional email all conspire against you. If you offer magic links, you also have to own deliverability — which means SPF, DKIM, DMARC, a warmed-up sender domain, and a fallback plan when an email is delayed.
What WRNexus does
By default, every workspace gets:
- OAuth for Google and GitHub (PKCE end-to-end, with
stateandnoncevalidation). - Magic links for anyone without a supported OAuth provider, with 15-minute, single-use tokens hashed at rest.
- Email + password with Argon2id hashing as the universal fallback.
Admins can disable any of these per-workspace. Most teams disable nothing; some enterprise customers turn off magic links because their mail gateways pre-click every URL, and some turn off OAuth to satisfy a “no third-party identity” compliance requirement.
Picking one for your product
If your audience is developers or anyone in a Google Workspace, ship OAuth first. The signup conversion alone will pay for the integration.
If your audience is less technical and uses a mix of personal emails, ship magic links first. Asking someone’s grandmother to “sign in with GitHub” is a usability disaster.
If your audience is enterprise IT, ship both, plus SSO via SAML or OIDC. Your buyer won’t accept anything less.
The under-discussed third option
We left passkeys off this comparison on purpose — they are the long game. Passkeys are phishing-resistant in a way neither OAuth nor magic links are. We covered them in detail in why we default to passkeys.
For now: pick OAuth, magic links, or both, knowing the trade-offs above. Add passkeys whenever your users are ready.