Magic Link Emails: How Passwordless Login Works

A magic link email authenticates a user without a password: the app emails a single-use, time-limited link, and clicking it logs the user in directly. There’s no code to read and retype, no password to recall, just one click that lands the user in an authenticated session. The whole mechanism depends on one thing: the token embedded in that link. It has to be generated with a cryptographically secure random source, stored as a hash rather than in plain text, scoped to expire quickly, and invalidated the instant it’s redeemed. Get any of those wrong and the link becomes a security hole instead of a login.

This post covers that token contract, the risks specific to email-based auth, and how magic links stack up against email OTP and traditional passwords.

How the Magic Link Flow Works

The flow replaces the password field with an email address field and moves the actual authentication step into a background token exchange:

1. User enters their email address, no password field
2. Server generates a token: CSPRNG(32 bytes) -> url-safe base64
3. Server stores sha256(token), user_id, expires_at, used = false
4. Server emails a link: https://app.example.com/auth/verify?token={raw_token}
5. User opens the email and clicks the link
6. Server looks up sha256(incoming_token), checks expiry and used flag
7. If valid: create a session, set used = true, redirect into the app
8. If invalid or expired: show a "request a new link" prompt

The token is the entire authentication factor. There’s no password to fall back on, which is why steps 2 and 3, generation and storage, carry more weight here than in a standard login form.

The Token Contract: What Makes a Magic Link Secure

The security properties are the same ones OWASP defines for any single-use authentication link. The OWASP Forgot Password Cheat Sheet requires tokens to be “generated using a cryptographically secure random number generator” and “long enough to protect against brute-force attacks,” in practice at least 128 bits of random data encoded into the URL. The same guidance requires tokens to be “invalidated after they have been used.” For a magic link that means the first successful click, since there’s no separate password-change step to wait for the way there is in a reset flow.

Two properties matter more here than they do for a password reset link:

• Expiry window. The link is the entire login, not a detour to a form, so it can and should expire fast. Supabase’s documentation states its default magic links “expire after 1 hour,” but most security-conscious implementations cut that to 15 to 30 minutes to shrink the window an intercepted email stays useful.
• Storage. Store a hash of the token (SHA-256), never the raw value. A database read doesn’t hand an attacker working login links.

Security Risks Specific to Magic Links

Link interception. A magic link is a bearer credential: whoever holds it is logged in, no additional check required. That makes forwarded emails, shared inboxes (support teams, family accounts), and browser history on a shared computer genuine attack surfaces in a way a password alone is not.

Email security scanners that burn the token before the user clicks it. Corporate, university, and hospital email systems commonly run inbound links through security scanners that fetch the URL to inspect it before the message reaches the inbox. That fetch consumes a single-use token. A maintainer described the pattern directly in a Supabase engineering discussion: “magic links and password reset links are frequently consumed by automated email scanners in enterprise, university, and hospital environments,” adding that “the root cause… is usually mail infrastructure prefetching the URL.” The user then clicks a link that’s already dead and sees an opaque error. Common mitigations: wrap the token inside a URL fragment so scanners fetch the landing page but never see the token (fragments aren’t sent to the server on a plain GET), and require an explicit click or button press on that landing page before the token is actually redeemed.

Same-browser, same-device requirements. Some implementations tie the request to the browser session that initiated it, which breaks a common real pattern: a user requests the link on desktop Chrome, but their phone’s mail app opens it in a different default browser. Auth0 flags this directly in its own passwordless documentation, noting that “both the initial request and its response must take place in the same browser or the transaction will fail,” and that this trips up iOS users specifically because “the user might make the initial request using the Chrome browser, but when the user opens the Magic Link in their email, iOS automatically opens it in Safari.” If your implementation has this constraint, budget for a visible “resend the link” path as a normal part of the flow, not an edge case.

Email account takeover. If an attacker controls the recipient’s inbox, they control every magic link sent to it, with no separate password to reset as a checkpoint. This is the core tradeoff of any email-based authentication method, and it has no mitigation at the application layer: there’s no “old password” to require, because there isn’t one.

Magic Link vs. Email OTP vs. Password

	Magic Link	Email OTP	Password
User action	Click one link	Read a code, type it in	Recall and type a password
Cross-device friction	High unless the link opens where the session started	Low, the code can be typed on any device	None
Phishing via live relay	Harder, requires intercepting a URL click	Easier, a fake page can ask for the code and relay it in real time	Classic credential phishing
Exposed by email interception	Yes, the link is a bearer credential	Yes, for its short validity window	No email dependency
Underlying mechanism	Signed, single-use token	Same signed, single-use token, delivered as a short code	Separate: a stored, hashed credential

Supabase’s own architecture makes the overlap explicit: “email OTPs share an implementation with magic links,” per its passwordless email documentation. It’s the same signed, single-use token underneath, delivered as a clickable URL in one case and a typed code in the other. The choice between them is mostly a UX decision, not a security one. Magic links remove the step of typing but confine the user to whatever context they started the request in. OTP codes work on any device the user has in front of them, at the cost of retyping a code.

Why Delivery Speed Decides Whether Magic Links Work at All

A magic link with a 15-minute expiry is worthless if the email takes 12 minutes to arrive. Unlike marketing email, where a delay of an hour goes unnoticed, an auth email that lands late looks broken and pushes the user straight to “resend” or gives up. Postmark states the stakes plainly on its own deliverability page: “if it doesn’t hit their inbox instantly, they care, and then they email support,” and treats delays to major providers as an operational incident, noting that “even a 30-second delay to Hotmail addresses gets us out of bed in the middle of the night,” according to Postmark’s deliverability documentation.

Practical requirements on the sending side:

• Send magic link emails on a dedicated transactional stream, separate from marketing sends, the same separation any transactional email needs.
• Authenticate the sending domain (SPF, DKIM, DMARC) so the message isn’t held up for filtering before it reaches the inbox.
• Keep the email itself minimal: one link, one expiry statement, no images or tracking pixels that slow rendering or trip spam filters.

If you’re sending magic links through the same email API you use for other transactional mail, a dedicated stream and consistent authentication matter more than which provider you pick. Coldletter routes auth emails like this on their own authenticated stream, separate from lifecycle and marketing sends, for exactly this reason.

Frequently Asked Questions