In short
For most new products, email and password plus one OAuth provider is the correct starting point: familiar to users, well understood, and cheap to support. Add passkeys when you want to reduce password risk, magic links when your users are non-technical and infrequent, and SSO only when an actual enterprise deal depends on it. Build the account model to allow more methods later; ship one or two now.
Start from the risk, not the method
Before comparing options, answer one question: what does an attacker get if they take over an account?
A note-taking app and a payroll system justify different amounts of friction. Users tolerate security effort in proportion to what they believe is at stake, and they resent it when the proportion is wrong. Most over-engineered auth comes from skipping this question.
The second question: who are your users? Developers will happily use a password manager and a TOTP app. Occasional non-technical users will forget a password between sessions, and every forgotten password is a support ticket.
Email and password
Still the default, and still usually right for a first version.
For: universally understood, works everywhere, no third-party dependency, and users can recover access without you.
Against: you inherit real responsibility — hashing correctly, breach handling, reset flows, credential-stuffing defence. Password reset is a security-sensitive flow that teams routinely under-build.
Do it properly: hash with a modern algorithm designed for passwords, never a general-purpose hash. Do not impose composition rules that push people toward Password1!; length matters more. Check submissions against known-breached password lists. Rate limit both login and reset. Make reset tokens single-use and short-lived. Never reveal whether an address exists.
OAuth (sign in with Google, GitHub, Apple)
Usually the right second method, and sometimes the right first.
For: removes password handling entirely, faster signup, and the provider carries the security burden. If your users are all on Google Workspace, this is close to free.
Against: you depend on a third party for login. Accounts can be revoked or renamed. You still need an account model that survives someone changing their provider email or losing access to it — the account-linking edge cases are where this gets genuinely fiddly.
Practical rule: offer one or two providers your users actually have, not five. Every additional button adds a decision and an account-collision path.
Magic links
Email a one-time link instead of a password.
For: no password to forget or leak. Excellent for infrequent, non-technical users. Removes an entire class of support ticket.
Against: login now depends on email deliverability and speed — if your mail lands in spam, nobody can log in, which turns a mail problem into an outage. Awkward when the link opens in a different browser from the request. Corporate scanners occasionally consume single-use links before the user clicks.
Consider when: users log in occasionally and you already send transactional email reliably.
Passkeys
Device-bound credentials using biometrics or a device PIN.
For: genuinely resistant to phishing, because the credential is bound to your domain and cannot be handed over. Faster than typing anything. Well supported across current browsers and platforms.
Against: the mental model is still unfamiliar to many users, and account recovery is the hard part — a passkey lives on a device, and people lose devices. You will still need a fallback method, which means passkeys usually reduce rather than replace other auth.
Consider when: you have accounts worth protecting and users on modern devices. Offer alongside an existing method rather than instead of one.
SSO (SAML, OIDC)
Authentication delegated to a company's identity provider.
For: required by many organisations above a certain size. Their IT controls provisioning and revocation, which is a real security benefit and often a procurement requirement.
Against: substantially more work than it looks — provider quirks, testing against systems you do not control, and ongoing support. It also drags in adjacent expectations: directory sync, role mapping, audit logs.
The rule that saves money: build SSO when a real deal depends on it, not before. It is the most commonly over-built auth feature in early products, and it is much easier to justify the work with a signed contract in hand.
Two-factor
Orthogonal to the above — a second factor on top of a first.
TOTP apps are the sensible default. SMS is materially weaker because of SIM-swap attacks, though it is better than nothing and some users will use nothing else. Offer recovery codes at enrolment and make clear they are the way back in.
Require it for privileged accounts. Offer it for everyone. Forcing it on consumer accounts with low stakes mostly generates support load.
A reasonable default
For most new products: email and password, plus one OAuth provider your users already have. Add TOTP as optional. Design the account model so one user can hold multiple auth methods, because you will add more later.
Then add, when there is a reason: - Passkeys — when accounts are worth protecting and you want phishing resistance - Magic links — when users are infrequent and non-technical - SSO — when an enterprise deal requires it
What matters more than the choice
Session handling, honestly. Most real incidents come from sessions that never expire, tokens in localStorage where any script can read them, no revocation on password change, and no way for a user to see or end their active sessions.
Get session handling right and a simple auth method is fine. Get it wrong and the most sophisticated login flow available will not save you.
If you are deciding this for a product with real accounts to protect, book a call — it is much cheaper to settle before launch.
Common questions
What is the best authentication method for a new app?
Email and password plus one OAuth provider your users already have. It is familiar, cheap to support, and does not depend on a single third party. Design the account model so a user can hold several auth methods, then add passkeys, magic links, or SSO when there is a specific reason.
When should I add SSO?
When a real enterprise deal depends on it, and not before. SSO is substantially more work than it appears — provider quirks, testing against systems you do not control, and the adjacent expectations of directory sync, role mapping and audit logs. It is the most commonly over-built auth feature in early products.
Are magic links more secure than passwords?
They remove password reuse and leakage, which is a genuine gain, but they move your login's reliability onto email deliverability — if your mail lands in spam, nobody can log in. They also behave awkwardly when the link opens in a different browser, and corporate scanners sometimes consume single-use links before the user clicks.
Should I use passkeys instead of passwords?
Alongside rather than instead, for now. Passkeys are genuinely phishing-resistant because the credential is bound to your domain, but they live on devices and people lose devices, so account recovery remains the hard part. You will still need a fallback method.
Is SMS two-factor authentication safe?
It is materially weaker than a TOTP app because of SIM-swap attacks, but meaningfully better than no second factor at all. Offer TOTP as the default, keep SMS only if a segment of your users will not use anything else, and always provide recovery codes at enrolment.
