Cobra Developers
Blog, Web apps

Passwordless login with magic links: pros, cons, and how it works

The short answer

A magic link is a one-time sign-in link emailed to a user in place of a password. The user enters an email address, clicks the link, and is signed in. It removes forgotten and reused passwords, but depends on email delivery and the security of the inbox. Links must expire quickly and work only once.

Two of our products have no passwords at all. On RankAZona, business owners edit their own directory profile through an emailed link. On Seal My Record Now, people sign in to passwordless accounts to return to their saved screenings and orders.

Both suit people who visit rarely. A business owner updates a profile now and then, not daily. Asking that person to invent, remember, and reset a password is asking for a support request. An emailed link asks for nothing they do not already have.

It is not the right choice everywhere, and it has to be built carefully. Here is how it works and where the trade-offs are.

A magic link login is a way to sign in without a password. The user types an email address, the site emails a link containing a secret one-time token, and clicking that link proves the person controls the inbox. The site then starts a normal signed-in session.

The idea is simple: access to the email account is the credential. That is already true of most password systems, since "forgot password" sends a reset link to the same inbox. A magic link skips the password and uses the reset step as the front door.

A magic link works in six steps: the user submits an email address, the server creates a random token, stores a hash of it with an expiry time, and emails a link containing the token. When the link is opened, the server checks the token, marks it used, and signs the user in.

  1. The user enters an email address and submits the form.
  2. The server generates a random token long enough that it cannot be guessed.
  3. The server stores a hash of the token, along with the email address and an expiry time. The raw token is not saved.
  4. The server emails a link that contains the raw token.
  5. The user clicks the link. The server hashes the token from the URL, looks for a matching unexpired, unused record, and marks it used.
  6. The server creates a session, usually a secure cookie, and the user is signed in.

Creating the token takes a few lines in Node:

import { randomBytes, createHash } from 'node:crypto';

const token = randomBytes(32).toString('base64url');
const tokenHash = createHash('sha256').update(token).digest('hex');
// Save tokenHash with the email and an expiry time. Email the raw token.

Storing only the hash means a leaked database does not hand anyone a working link.

Magic links remove the problems passwords cause, such as weak, reused, and forgotten passwords, and they make signing up nearly effortless. In exchange, every sign-in depends on an email arriving promptly, and the account is exactly as secure as the user's inbox.

ProsCons
No password to forget, reuse, or leakSign-in fails if the email is slow or lands in spam
No password database to protectSecurity depends on the user's email account
Sign-up and sign-in are the same short formSwitching to the inbox and back is slower for daily users
Confirms the email address on every sign-inShared inboxes mean shared access
Fewer reset requests to supportLink scanners in some mail systems can open links first

The cons are real. If people sign in to your product several times a day, waiting for an email each time gets old. For that kind of use, a password with a second factor, or a passkey, is the better fit.

Make magic links secure with four rules: tokens must be long and random, they must expire within minutes, they must work only once, and only their hash is stored. Add rate limits on requests, and give the same response whether or not the email address has an account.

The details behind those rules:

  • Short expiry. A link that works for days is a password sitting in an inbox. Minutes is the right scale.
  • Single use. Once a token signs someone in, it is dead. A second click gets a fresh request form.
  • Rate limiting. Limit how many links can be requested for one address and from one source, so the form cannot be used to flood an inbox.
  • No account hints. Reply "if that address is registered, a link is on its way" in every case, so the form does not reveal who has an account.
  • Send it over HTTPS only, and do not log full URLs that contain tokens.

One trap deserves its own mention. Some email systems open every link in a message to scan it before the person does. If opening the link consumes the token, the real click fails. The fix is to have the link lead to a page with a confirm button, and consume the token only when that button is pressed.

Where a change matters, add a second check. On RankAZona, an owner's edits are staged, verified, and applied on a schedule, not written to the live profile the instant a link is clicked.

Magic links are the right choice when users sign in occasionally, the audience is not technical, and the email address is already the main way you reach them. They are a poor choice for tools used many times a day, shared inboxes, and accounts that guard highly sensitive actions without a second factor.

Good fits, from our own work: a directory where an owner updates a listing now and then, and a consumer service where someone returns to check an order. In both, a password would be forgotten between visits.

Poor fits: an internal tool staff live in all day, or anything where email delivery is unreliable for your audience. Many products offer both and let the user pick. For the wider picture on protecting accounts, see website security basics, and for the email side, see SMS and email notifications in apps.

Frequently asked questions

For most ordinary users, yes, because they remove weak and reused passwords, which are common causes of account takeover. They are not safer than a strong unique password combined with a second factor. The security of a magic link equals the security of the email account behind it.

The user cannot sign in, which is the main weakness of the approach. Reduce the risk by sending from a properly authenticated domain, keeping the email plain and short, offering a resend button, and telling users to check spam. Some products add a typed one-time code as a fallback.

That is a design decision. Allowing it is convenient, since people often request on a laptop and read email on a phone. Requiring the same browser is stricter but causes failed sign-ins. Many products allow any device and rely on short expiry and single use for safety.

No. A passkey is a cryptographic credential stored on the user's device and unlocked with a fingerprint, face, or device PIN. No email is involved. Passkeys are faster for frequent sign-ins. Magic links need nothing set up in advance, which suits occasional visitors.

They can, but add a second factor. An admin account protected only by one inbox is a single point of failure, and admin access is worth the extra step.

If you are deciding how people should sign in to something you are building, tell us who your users are and how often they will visit. That usually settles it.

Who wrote this

The Cobra Developers team. We are a software studio in Arizona that builds and runs its own products and builds websites, web apps, and automation for clients. This post draws on our work on RankAZona, Seal My Record Now. Everything here comes from projects we shipped; see all 30 of them.

guest@cobra: ~