Magic Links: How Passwordless Email Login Works

A magic link is a login method where, instead of typing a password, a user enters their email address and receives a single-use link that logs them in when clicked. There’s no password to create, remember, or leak — the email account itself becomes the credential, and possession of that inbox is what proves identity.

The flow, step by step

1. The user enters their email on the login form and submits.
2. The server generates a random, high-entropy token, stores it (usually hashed, alongside the associated user ID and an expiry timestamp), and emails a link like https://example.com/auth/verify?token=abc123....
3. The user opens their inbox and clicks the link.
4. The server looks up the token, checks it hasn’t expired or been used already, and if valid, establishes a session — typically by setting a session cookie or issuing a JWT.
5. The token is immediately invalidated so the same link can’t be reused.

The whole exchange hinges on one assumption: that only the legitimate account owner can read email sent to that address. That’s a reasonable assumption for most consumer products, and a shaky one for shared or institutional mailboxes.

Why teams adopt it

Magic links eliminate an entire category of problems tied to passwords: there’s no password database to breach, no reused-password risk across sites, and no “forgot password” flow to build separately — the login flow and the reset flow become the same flow. For low-friction signups, it also removes a real conversion barrier: users don’t have to invent and remember yet another password for a service they might use once.

It’s a meaningfully different trust model than OAuth, where a third-party identity provider vouches for the user. With a magic link, your own application still owns the identity — it’s just outsourcing the “prove you’re you” step to whichever mail server hosts that inbox.

Where the risks are

• Email account compromise becomes account compromise. If someone’s inbox is breached, every magic-link-protected account tied to it is exposed too. This is the same underlying risk as email-based password resets, just made into the primary login path instead of a fallback.
• Link forwarding and leakage. A magic link is a bearer credential for a short window — anyone who has the URL can use it. Corporate proxies, email security scanners, and browser extensions that “pre-fetch” links to check for phishing can accidentally consume a one-time token before the real user clicks it, which is a genuine operational headache, not a theoretical one.
• Short expiry is essential. Tokens should expire in minutes, not hours, and must be single-use — checked and invalidated atomically to avoid a race where a token gets used twice before the “used” flag is written.
• Shared devices and shared inboxes. A support inbox or a shared family email account breaks the one-person-per-token assumption entirely.
• Phishing surface. Users are trained to click links in emails claiming to be a login prompt — which is also exactly what a phishing email looks like. A well-designed magic link flow should make the sender and destination domain unmistakable.

Mitigate the worst of this by binding the token to the session that requested it (so a token generated in one browser can only complete login in that same browser), rate-limiting how often a given email can request a new link, and logging the request’s IP and user agent for anomaly detection.

Magic links vs. other passwordless methods

	Magic links	Passkeys	One-time passwords (OTP)
What proves identity	Access to an email inbox	A device-bound cryptographic key	A code, usually sent by SMS or email
Phishing resistance	Low — a real link can be intercepted or forwarded	High — bound to the origin, can’t be replayed elsewhere	Low — codes can be relayed to attackers
Setup friction	None — just an email address	Requires platform/device support	Low, but requires a phone number or app
Works across devices	Yes, if the inbox is accessible	Requires the same key or a synced passkey	Yes

Passkeys are the stronger long-term answer where they’re supported, since the credential is cryptographically bound to the site’s origin and can’t be phished the way a URL or a code can. Magic links remain popular precisely because they require nothing from the user beyond an email address they already have — no app to install, no hardware key, no platform-specific setup. Some products layer both: a magic link for initial signup, with an option to register a passkey afterward for faster, more phishing-resistant returns.

Implementation notes

Store tokens hashed, the same way you’d store a password, so a database leak doesn’t hand out working credentials. Set the verification link’s cookie with SameSite=Lax at minimum so the session can be established from a top-level navigation (the click itself) without being vulnerable to cross-site request patterns. And always pair the flow with basic anti-automation controls — a login form that emails a link to any address on request is also a free tool for enumerating which email addresses have accounts, unless you respond identically whether or not the address exists.

The takeaway

Magic links trade the password’s shared-secret model for a possession-based one: whoever controls the inbox controls the account. That’s simpler to build and easier for users than password management, but it inherits every risk of the underlying email system, and it’s more phishable than a properly implemented passkey. Use short-lived, single-use, session-bound tokens, rate-limit generation, and treat it as one option in a passwordless toolkit rather than a strictly superior replacement for stronger, origin-bound credentials.