How would you design a secure magic-link login?

Prompt and context

A low-risk SaaS wants users to enter an email address and receive a one-time login link. Design request, delivery, verification, session establishment, revocation, and audit flows. Cover a compromised mailbox, forwarded links, mail prefetch, replay, rate abuse, and high-risk actions.

What the interviewer is testing

• Whether you use unpredictable, short-lived, single-use tokens.
• Whether you prevent account enumeration, log leakage, and brute-force verification.
• Whether you distinguish convenience from assurance and phishing resistance.
• Whether sessions, revocation, notifications, audit, and fallback are complete.

Clarifying questions before answering

Confirm business risk, verified email status, multi-device behavior, link lifetime, mail provider, MFA, and high-risk operations. Payments, privilege changes, and sensitive data need phishing-resistant or additional authentication, not email as the only high-assurance factor.

30-second answer framework

Generate a high-entropy random token and store only its hash, purpose, user, expiry, and consumed state. Return the same response for existing and unknown addresses and rate-limit requests. Verify over HTTPS, consume the token atomically, then create a short-lived session and rotate its identifier. Allow one use, audit failures and unusual devices, and revoke when needed. The security of a magic link inherits mailbox and browser-channel risks, so it is not automatically phishing-resistant or suitable for every NIST assurance level.

Step-by-step deep dive

1. Generation and storage

Use a cryptographically secure random value as a one-time URL parameter; store its hash rather than plaintext. Record purpose, user, creation and expiry times, consumption time, and request context. Compare hashes in constant time and limit attempts.

2. Request and verification

Return the same message, timing envelope, and status for every email to avoid enumeration. Rate-limit by IP, address, device, and global budget, with a mail-send quota. Verification must mark the token consumed in a transaction or atomic conditional update, preventing two concurrent clicks from replaying it.

3. Session and risk controls

After consumption, rotate the session identifier, set a secure cookie, and notify the user about device and location. Mail prefetchers and scanners may visit a link first; use an intermediate confirmation page and explicit user action. Require reauthentication, MFA, or WebAuthn for sensitive operations rather than turning a link into a long-lived privileged credential.

High-quality sample answer

I define magic links as a convenient factor for low-risk access, not a universal phishing-resistant authenticator. After a request, the service uses a CSPRNG, stores only a hash, purpose, expiry, and consumed state, and returns the same result for every address. The verifier looks up the hash over HTTPS, atomically marks it consumed, rotates the session ID, sets a secure cookie, and records an audit event. Links are short-lived and revocable; their URLs must stay out of logs and analytics. To handle prefetch, show a confirmation page and require a deliberate click. For forwarding and multiple devices, define whether one consumption is allowed and how to notify the account owner. Payments and privilege changes use MFA or WebAuthn. Tests cover replay, concurrent clicks, enumeration, rate limits, mail leakage, anomalous devices, and revocation.

Common mistakes

• Storing plaintext tokens in databases or logs.
• Failing to consume atomically, allowing concurrent replay.
• Returning a different error for an unknown address and enabling enumeration.
• Calling magic links inherently phishing-resistant or equivalent to a hardware key.
• Exchanging an expired link for a long-lived session or omitting notification and revocation.

Follow-up questions and responses

What about mail-client prefetching?

Do not complete login on a GET visit. Show a confirmation page, consume the token only after explicit user action, and distinguish prefetch telemetry from a real click.

How long should a token live?

Choose a short window from risk and mail-delay budgets, then monitor replay and unused rates. After expiry, issue a new token rather than extending the old one.

Why not use it for administrators or payment approval?

Mailbox channels can be forwarded, hijacked, or phished, and NIST separates some email confirmation uses from high-assurance authentication. High-risk actions need phishing-resistant authentication, transaction binding, and independent notification.