What Actually Happens When You Click "Email Me a Link"
You type your email into a login box, no password field in sight, and a message appears: check your inbox. A minute later there's an email with a button that says "Sign In" or "Log In to Your Account". You click it, and you're in. That's a magic link, one of the more common forms of passwordless authentication, and understanding what happens on the server between your click and your inbox is the key to understanding both why it's convenient and where it can bite you.
The Server-Side Mechanics
Under the hood, a magic link is built and checked in a fairly small number of steps:
- Token generation. When you submit your email, the server generates a long, cryptographically random string, not something guessable like a counter or a timestamp. This token gets stored server-side, tied to your account and a short expiry window, usually somewhere between five and thirty minutes.
- Delivery. The token is embedded into a URL, something like
yoursite.com/login/verify?token=followed by the random string, and that URL is emailed to the address on file. Note that the email itself is the only channel carrying the secret; nothing is sent to your browser yet. - Validation on click. When you click the link, your browser sends that token straight to the server. The server looks it up, checks that it exists, hasn't expired, and hasn't already been used once before, then immediately marks it as consumed so the same link cannot log in a second person.
- Session issuance. Only after that check passes does the server create a normal logged-in session for your browser, typically a session cookie, and the token itself is discarded.
The entire security model rests on one assumption: whoever clicks that specific link, within that specific window, is the account owner, because only the account owner should have received the email. It's the same trust assumption your "forgot password" flow already uses today, just promoted from an emergency backup path to the primary way you log in every single time.
Why Product Teams Keep Choosing This
From a service's perspective, magic links solve several expensive problems at once. There's no password database to encrypt, salt, and defend, which removes an entire category of breach exposure since there's simply nothing to steal if the user table is dumped. Signup forms get shorter, since there's no "create a password" and "confirm password" pair with strength meters scaring off new users. And support tickets about forgotten passwords disappear entirely, replaced by a problem users already know how to solve: check your email.
Where the Convenience Costs You Something
Nothing here is free, and the tradeoffs are worth being honest about rather than glossing over.
Your email account becomes the master key to everything. If ten different services all authenticate you through magic links, then whoever controls your inbox, permanently or just for the five minutes after you click "forgot" or "login", can get into all ten. This is precisely why an email account protected only by a weak password is a much bigger liability under a magic-link-heavy workflow than it was in a world of separate per-site passwords. It's worth pairing this style of login with genuinely strong 2FA on the email account itself, since that account is now doing double duty as your recovery mechanism for everything.
The link is a bearer token, and bearer tokens can travel. Anything that can leave your inbox intact, forwarding the email to a colleague, a screenshot posted somewhere, an assistant with inbox access, hands the recipient a working login, no password or biometric check required on their end. The system has no way to know the person clicking isn't you.
Links sit in places you don't expect. Browser history, email search indexes, corporate email archiving and DLP scanners, and shared-computer autofill all potentially retain a copy of a link that, until it expires, still works.
Real-world phishing works here too. A convincing fake "sign in to your account" email pointing to a lookalike domain works exactly as well against magic link users as against password users. Some attackers go a step further: trigger a genuine magic link email on the real service, then socially engineer the victim into forwarding or reading it aloud, an approach that mirrors classic phishing tells almost exactly.
It requires connectivity at the worst possible moment. No inbox access, no login, full stop. Compare that to an authenticator app or a passkey, both of which work completely offline once set up.
Magic Links Against Password Plus 2FA
The natural comparison is a traditional password paired with a second factor, since that's the setup magic links most often replace. Password plus TOTP requires two independent things to fail at once for an attacker to get in: they need your password and your authenticator app or its seed. A magic link, on its own, requires exactly one thing to fail: access to your inbox at the right moment. That makes a bare magic link, with no second factor layered on top, roughly comparable in strength to a single factor, not two.
Where magic links pull ahead is against credential stuffing and reused passwords specifically. There is no password to leak from this service, be guessed, or be replayed from some other breach, so an entire attack category is eliminated by design. For a user with historically poor password habits, trading a weak, reused password for a magic link tied to a well-protected inbox is often a genuine net improvement, even without an extra factor bolted on.
Magic Links Versus Passkeys
Both are marketed as "passwordless," but they solve the problem in fundamentally different ways, and it shows in a side-by-side comparison.
| Magic Link | Passkey | |
|---|---|---|
| What proves it's you | Access to your email inbox | A cryptographic key stored on your device |
| Resistant to phishing | No, the link can be forwarded or relayed | Yes, cryptographically bound to the real domain |
| Single point of failure | Your email account | Your device or keychain, often with biometric unlock |
| Works offline | No, requires checking email | Yes, once registered |
| Setup effort for the service | Low, standard email sending | Higher, requires WebAuthn support |
Passkeys are the stronger option because the cryptographic handshake itself refuses to complete against a fake domain, so a phishing site gets nothing usable even if the victim tries to "log in" on it. Magic links remain popular anyway because they need no special hardware, no platform support, and no user education beyond "check your email," which is exactly why they show up as the default option on so many newer web apps.
Where a Magic Link Genuinely Makes Sense, and Where It Doesn't
Good fit: low-stakes services where friction kills signups, newsletters, community forums, trial signups, or internal tools where the userbase already has strong email security by policy. Poor fit: financial accounts, anything holding sensitive personal data, or any account where a five-minute inbox compromise translating into a full account takeover is a genuinely bad outcome. For those, a passkey, a hardware key, or a password with app-based 2FA on top gives you a second, independent barrier that a compromised inbox alone can't clear.
Frequently Asked Questions
What stops someone from just guessing a magic link token?
The token is a long, randomly generated string, not a short PIN, so brute forcing it directly is computationally infeasible within the few minutes before it expires. The realistic attack path is never guessing the token, it's getting access to the inbox that received it.
Can I reuse a magic link if I click it twice?
No, a properly implemented magic link is marked used the instant it succeeds once, so clicking it again fails even within the expiry window. This one-time-use design is what stops an email that got forwarded or archived from becoming a standing key.
Is it safe to use magic links on a shared or work computer?
Be cautious. If your email stays logged in on that machine, or archiving software retains a copy of the message, the link may remain functional longer than you expect, and anyone with access to that inbox or archive could use it. On shared machines, log out of email fully after use.
Do magic links protect against credential stuffing better than passwords?
Yes, completely, for that specific service, since there's no password field to have been reused elsewhere in the first place. It doesn't make the account unphishable or immune to inbox compromise, it just removes one specific, very common attack category.
Why do some services combine a magic link with a code as well?
To get genuine two-factor strength: the link proves inbox access, and a separate code, sent by SMS, generated by an app, or requiring a device you've already registered, proves something independent. Without that second, separate factor, the magic link alone is really just a single, cleverly delivered credential.
