A magic link must expire after one use so forwarding cannot reuse it

What it is

A magic link is mail or a message carrying a signed token; opening it creates a session without a password or short code. Expiring immediately after one use means the token is dead after the first successful redemption; the same URL cannot sign anyone in again. The abuse in view is forwarding and replay: the mail is forwarded to a colleague, screenshotted into a chat, or opened later from a copy. This entry does not rank links against short codes, and it does not require a second confirmation on the originating device.

Why it happens

The link encodes full sign-in capability in a URL. URLs are copied: forwarded, synced to another computer, found in full-text mail search, rewritten by a security gateway and visited again. If the token remains valid after a successful redemption, the second open is a second sign-in, and the session lands with whoever clicked. Single-use collapse “proof of inbox possession” into “the first click”; later copies become dead links. Successful redemption is not the same as a failed open: prefetch bots, link scanners, and “safe browsing” in mail clients hit the URL first; if that hit burns the token, the human arrives too late. One-time must be bounded on authentication success, not on the first HTTP GET. The person should see “this link was already used,” not “sign-in failed,” which sounds like a wrong password.

Studying it

Build two sequences—“successful redemption then the same URL again” and “scanner GET then human click”—and watch whether the second becomes a session.

Independent variables: invalidation trigger (any GET, only after a session is created, only the POST redemption endpoint), whether prefetch and redemption are different endpoints. Dependent variables: whether the second open is signed in, whether a human can still redeem after scanner prefetch, whether a forwarded second person gets a session, false “already used” rate.

Do not treat two clicks in the same lab browser as “forwarding”—forwarding crosses browsers, IPs, sometimes people. Gateway prefetch varies by vendor; the matrix needs at least one gateway or enterprise scanner that opens links. Guess limits are not the same independent variable; short codes are what mainly need a guess cap.

Where it stops holding

Someone may open the link on a phone and want the desktop session to continue; after single-use, the desktop must ride an already-created session or request a new link, not the same URL. In a shared inbox, whoever clicks first is signed in and the next person is locked out—that is a shared-identity problem, not a reason to make the token multi-use. When the link is only a deep link into an app whose session comes from elsewhere, invalidation follows the session token, not this rule. Password-reset links are often single-use too, but they aim to change a secret rather than mint a login session; that expiry belongs to recovery.

Applying it

• Invalidate the token only after authentication succeeds (session established, or a one-time ticket swapped for a session). Keep prefetch HEAD/landing distinct from the one-time redemption endpoint.
• On the second open, show “this link was already used; if it was not you, change the password or sign out other sessions,” with a path to request a new link—not “account or password incorrect.”
• Log device and coarse location of the redemption for later “that was not me” review; that is audit, not a device-side second factor.
• Verify: after browser A signs in successfully, open the same URL in browser B; B must not get a session. Then run a mail scanner that prefetches links; a human should still redeem exactly once afterwards.

Related

• Within the group: H6.03.1 OTP fields must accept paste and autofill · H6.03.2 OTP expiry and resend interval must be visible · H6.03.3 SMS failure needs a fallback channel · H6.03.5 Limit OTP guesses to stop brute-force enumeration · H6.03.6 Magic links and OTP codes are not equivalent authenticators · H6.03.7 Passwordless login still needs a device-side confirmation against intercepted links
• Adjacent: H6.11 Password recovery and reset · H6.06 Multi-device sessions
• Search terms: magic link · single-use token · email link replay