Walk me through a magic link login system and its security considerations

WHAT THIS TESTS: This question tests whether you can design a distributed authentication flow that balances growth goals with security rigor. Interviewers want to see that you understand token lifecycle management, session hygiene, and threat modeling in an email-based passwordless system rather than treating it as a simple send a link feature.

A GOOD ANSWER COVERS: First, the request phase: the user submits an email, the backend checks for account existence without revealing it via timing or error messages to prevent enumeration, then generates a high-entropy cryptographically random token stored hashed in a short-lived table. Second, delivery: the token is embedded in a HTTPS URL and sent via email over TLS; the plaintext token never leaves the server unhashed. Third, consumption: clicking the link sends the token to a validation endpoint that checks expiry typically 15 minutes or less, confirms the token hash matches, marks it consumed immediately to prevent replay, and then creates an authenticated session. Fourth, hardening: rate limiting on both request and validation endpoints to slow brute force and abuse, device or IP binding for the session to reduce token forwarding risk, and clear fallback paths for expired or undelivered links. Fifth, revocation: the ability to invalidate outstanding tokens on suspicious activity or email compromise.

COMMON WRONG ANSWERS: Treating the magic link as a long-lived bearer credential that replaces a password rather than a single-use bootstrap mechanism. Storing tokens as plain text or using short predictable strings instead of 128-plus bit random values. Proposing JWTs for the magic link token, which complicates revocation and encourages longer lifetimes. Ignoring the risk of email interception by omitting TLS requirements or failing to mention that email is generally not a confidential channel. Forgetting to handle the race condition where a user clicks the link multiple times or forwards it to another device.

LIKELY FOLLOW-UPS: How would you handle a user requesting multiple links in quick succession? Would you invalidate previous tokens or allow a small window of parallel valid tokens? How do you prevent an attacker from using the link on a different device if the user forwards it? What happens if the email provider scans the link and pre-fetches it, consuming the token before the user clicks? How would you combine magic links with multi-factor authentication for high-risk actions?

ONE CONCRETE EXAMPLE: A senior candidate might describe a flow where the token is a 256-bit random value hashed with SHA-256 and stored in Redis with a 900 second TTL. On request, the system checks a per-email rate limit of five requests per hour. The email contains a URL like app.com/auth/magic with the plaintext token as a query parameter. When consumed, the endpoint hashes the incoming token, looks it up in Redis, deletes the key immediately on match, issues an HTTP-only SameSite strict session cookie, and rotates the session ID. If the user agent or IP differs significantly from the request phase, the system requires an additional OTP step before full authentication.

Source: loginradius.com