Magic Links Under Replay, Forwarding, and Email Security Scanners

Do not authenticate on the first GET to a magic-link URL. Treat that request as navigation to an interstitial, then require an explicit user action that submits a one-time credential. Keep the credential short-lived, single-use, narrowly bound, and observable for replay. This separates automated URL inspection from intentional sign-in without making a captured link reusable.

Assume the link will be visited early

Enterprise mail systems inspect and rewrite URLs. Microsoft documents that Safe Links scans and rewrites email URLs, can check them before delivery, and performs time-of-click verification. Other gateways and preview generators may also fetch links. If a GET consumes the credential and creates a session, a scanner can invalidate the message before the person opens it or, in a worse design, create authentication state in an unrelated user agent.

The initial GET should be safe and idempotent. It can validate basic token structure and display “Continue to sign in,” but it should not consume the credential or set an authenticated session. The confirmation POST carries the token through a form field or server-held transaction reference and applies CSRF protection. Prevent framing and avoid loading third-party assets that receive the sensitive URL through referrers. Remove the token from the address bar as soon as the transaction is established.

Bind and consume the credential

Generate a high-entropy random token, store only its hash, and bind the record to purpose, identity, issue time, expiry, and intended client or redirect allowlist. Consume it atomically when authentication succeeds. A second submission returns a generic expired-or-used response and produces a replay signal. Rate-limit issuance and verification by destination, identity, and network indicators without enabling account discovery.

Forwarding remains a property of email possession: anyone who receives the live link may be able to use it. Reduce exposure with a short lifetime and a confirmation page that names the action. For higher-risk accounts, bind the flow to a browser that initiated login using a separate same-device nonce, or require an additional factor. Same-device binding improves resistance to forwarded links but breaks cross-device flows and some accessibility workflows; make the tradeoff explicit.

OWASP’s Authentication Cheat Sheet recommends reauthentication after risk events, generic authentication responses, and layered protection against automated attacks. Apply those principles here: do not reveal whether an address exists, rotate the session at successful login, and require step-up before sensitive settings changes even after a magic-link login when policy demands it.

Preserve user intent through the flow

Bind only an allowlisted post-login destination. Never accept an arbitrary redirect from the link. If the user started in tenant Acme, store the immutable tenant context in the server-side transaction and recheck membership after authentication. Do not let the link itself grant a role or membership; invitations and login are separate state transitions.

Ory Kratos is an API-first identity and user-management system with self-service flows and a custom user-interface option, as summarized in the Ory Network Kratos introduction. Ory Network provides the managed path, while self-hosted Ory Kratos is a distinct deployment choice. Teams should test the surrounding email, redirect, and session behavior for the flow they implement.

Test real delivery infrastructure

Send test messages through the major gateways your customers use and record whether URLs are rewritten, prefetched, or visited more than once. Test scanner GET, user POST, forwarded link, replay after success, two tabs racing, expiry during confirmation, and login initiated on one device but completed on another. Verify that only the confirmation action creates a rotated authenticated session.

The next step is to inspect one production magic-link flow and prove that a plain GET has no authentication side effect. Review by 2026-12-05 or when email security, identity flow, or browser policy changes.