Passwordless Auth with Magic Links: Why and How

Passwords are a liability. Users forget them, reuse them across sites, and lose them to phishing. Magic link authentication removes the password entirely — users enter their email, receive a one-time login link, and click to authenticate. No password to remember, no credential database to breach.

Why Magic Links Beat Passwords for Most Apps

For B2B SaaS and business applications, magic links are often a better default than passwords. Your users are professionals who check email constantly. They don't want to remember another password — they just want to get into the tool and do their work.

Magic links are also more secure than passwords for most threat models. A time-limited, single-use token sent to a verified email address is harder to brute-force than a password. The attack surface moves from your password database (which hackers target) to the user's email account (which is already secured by Google or Microsoft).

How Magic Links Work

The flow is straightforward. The user submits their email address. Your server generates a cryptographically secure random token, stores it in the database with an expiry time (15–60 minutes is typical), and sends an email containing a URL with the token as a parameter.

When the user clicks the link, your server validates the token: is it in the database? Has it expired? Has it already been used? If all checks pass, you create the session, invalidate the token, and redirect to the app. The token is single-use — clicking the same link twice does nothing after the first use.

Implementation in Laravel

Laravel doesn't ship with magic links out of the box, but the implementation is clean. Generate a token with Str::random(64), store it in a magic_links table with the user email, token hash, and expiry timestamp. Send the email with a signed URL or the raw token as a query parameter.

On the validation endpoint, find the token record, check it hasn't expired (compare expires_at to now), check it hasn't been used (a boolean flag or deletion), then log the user in via Auth::login() and invalidate the token.

Use hash_equals() for token comparison to prevent timing attacks. Never store tokens in plain text — hash them with SHA256 before storing and compare hashes on validation.

When to Use Magic Links vs Other Methods

Magic links work best when users are on a device with reliable email access and aren't logging in constantly. They're ideal for B2B tools, admin dashboards, and low-frequency apps.

They're less suitable for high-frequency apps where users log in multiple times daily — the friction of checking email each time adds up. For those cases, session persistence (stay logged in for 30 days) combined with magic links for re-authentication is a good balance.

For mobile apps, magic links can trigger an app deep link — the email contains a link that opens directly in the app rather than a browser. This keeps the experience smooth on iOS and Android.

Security Considerations

Set a short expiry — 15 to 30 minutes is enough. A longer window increases the risk window if an email is intercepted. Make tokens single-use and delete them immediately on first use. Rate-limit the magic link request endpoint to prevent email flooding attacks.

If you want an extra layer, include the user's IP or browser fingerprint in the token validation and warn (but don't block) if it differs from the requesting client. This catches cases where an attacker intercepts the email and clicks the link from a different device.