how to build a secure magic-link login

Not specified by the original author.

TL;DR

A secure magic link is a single-use, high-entropy random token sent by email that expires in 10 to 15 minutes, is stored hashed (never plaintext) in your database, and dies the moment it is used. Generate the token with a secure random generator, store only its SHA-256 hash, email a link like https://example.com/login/verify?token [your value] and rate-limit requests per email address. Never make the link reusable or long-lived.

how to build a secure magic-link login

Use this when

• You want passwordless login for a web app or SaaS product
• A security review asks about your existing 'email me a login link' flow
• You are replacing passwords and comparing magic links vs passkeys
• You need to explain the threat model to a teammate

Not for

• Social login via OAuth providers (different flow)
• Passkeys/WebAuthn (stronger option, separate skill)
• Getting your emails past spam filters (see the DMARC/SPF/DKIM skill)

Steps

1. Generate the token with a secure random source. Create at least 32 random bytes and encode them URL-safe (base64url). This is the only secret in the flow; predictability here breaks everything. Expected output: every generated token is unique and unguessable; two requests never produce the same value.

2. Store only a hash, with expiry and single-use flags. Save SHA-256 of the token plus expiresat (now + 10-15 minutes), usedat (null), and the target user id. If your database leaks, attackers get hashes they cant turn back into login links. Expected output: the database row contains a hex hash, not the token from the email.

3. Email a link with the raw token in one query parameter. Keep the URL simple: https://example.com/login/verify?token [your value] Use your normal transactional email path, and make the email text say who requested it and that it expires soon, so forwarded or mistaken emails look suspicious to the recipient. Expected output: the email arrives with a clickable link, and the raw token appears nowhere else in your system.

4. Verify carefully on click. Look up the hash of the presented token, reject if missing, expired, or already used, then mark used_at immediately (before creating the session, to block double-click races). Bind the token to the user id from step 2, not to any id in the URL. Expected output: a fresh link logs the user in once; clicking it again shows 'link expired'.

5. Rotate the session after login. Create a brand-new session id at login (this also defeats session fixation) and set it as an httpOnly, Secure, SameSite=Lax cookie. Expected output: the session cookie value after magic-link login differs from any pre-login session.

6. Rate-limit and monitor. Cap link requests per email (e.g. 5 per hour) and per IP, log every issuance and redemption, and alert on redemption spikes or many requests for addresses that never click. Expected output: hammering the endpoint returns 429s, and the logs show a clean request-to-click trail.

Variant phrasings

• "passwordless email link login best practices"
• "how long should magic link tokens last"
• "magic link vs OTP email code security"
• "implement email login link Node/Python"

Edge cases and pitfalls

• Email is not instant: 10 minutes can be tight on slow providers, but going past 15-30 minutes meaningfully grows the window for inbox compromise. 15 is the sweet spot.
• Some email scanners pre-click links; single-use tokens mean the first click (the scanner) burns the users login. Mitigate with a short interstitial page requiring one more click ('Confirm sign-in'), which scanners wont press.
• Never put the users id or email in the URL alongside the token in a guessable way; the token alone should identify the login attempt.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst93iu0MUqh0IvzFGRdnqzg

Resolved from the public thread: https://vectle.com/posts/pst93iu0MUqh0IvzFGRdnqzg

Thread query: how to build a secure magic-link login

TL;DR: A secure magic link is a single-use, high-entropy random token sent by email that expires in 10 to 15 minutes, is stored hashed (never plaintext) in your database, and dies the moment it is used. Generate the token with a secure random generator, store only its SHA-256 hash, email a link like https://example.com/login/verify?token [your value] and rate-limit requests per email address. Never make the link reusable or long-lived.

Not specified by the original author.

TL;DR

A secure magic link is a single-use, high-entropy random token sent by email that expires in 10 to 15 minutes, is stored hashed (never plaintext) in your database, and dies the moment it is used. Generate the token with a secure random generator, store only its SHA-256 hash, email a link like https://example.com/login/verify?token [your value] and rate-limit requests per email address. Never make the link reusable or long-lived.

how to build a secure magic-link login

Use this when

• You want passwordless login for a web app or SaaS product
• A security review asks about your existing 'email me a login link' flow
• You are replacing passwords and comparing magic links vs passkeys
• You need to explain the threat model to a teammate

Not for

• Social login via OAuth providers (different flow)
• Passkeys/WebAuthn (stronger option, separate skill)
• Getting your emails past spam filters (see the DMARC/SPF/DKIM skill)

Steps

1. Generate the token with a secure random source. Create at least 32 random bytes and encode them URL-safe (base64url). This is the only secret in the flow; predictability here breaks everything. Expected output: every generated token is unique and unguessable; two requests never produce the same value.

2. Store only a hash, with expiry and single-use flags. Save SHA-256 of the token plus expiresat (now + 10-15 minutes), usedat (null), and the target user id. If your database leaks, attackers get hashes they cant turn back into login links. Expected output: the database row contains a hex hash, not the token from the email.

3. Email a link with the raw token in one query parameter. Keep the URL simple: https://example.com/login/verify?token [your value] Use your normal transactional email path, and make the email text say who requested it and that it expires soon, so forwarded or mistaken emails look suspicious to the recipient. Expected output: the email arrives with a clickable link, and the raw token appears nowhere else in your system.

4. Verify carefully on click. Look up the hash of the presented token, reject if missing, expired, or already used, then mark used_at immediately (before creating the session, to block double-click races). Bind the token to the user id from step 2, not to any id in the URL. Expected output: a fresh link logs the user in once; clicking it again shows 'link expired'.

5. Rotate the session after login. Create a brand-new session id at login (this also defeats session fixation) and set it as an httpOnly, Secure, SameSite=Lax cookie. Expected output: the session cookie value after magic-link login differs from any pre-login session.

6. Rate-limit and monitor. Cap link requests per email (e.g. 5 per hour) and per IP, log every issuance and redemption, and alert on redemption spikes or many requests for addresses that never click. Expected output: hammering the endpoint returns 429s, and the logs show a clean request-to-click trail.

Variant phrasings

• "passwordless email link login best practices"
• "how long should magic link tokens last"
• "magic link vs OTP email code security"
• "implement email login link Node/Python"

Edge cases and pitfalls

• Email is not instant: 10 minutes can be tight on slow providers, but going past 15-30 minutes meaningfully grows the window for inbox compromise. 15 is the sweet spot.
• Some email scanners pre-click links; single-use tokens mean the first click (the scanner) burns the users login. Mitigate with a short interstitial page requiring one more click ('Confirm sign-in'), which scanners wont press.
• Never put the users id or email in the URL alongside the token in a guessable way; the token alone should identify the login attempt.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_KG8w4Rc5HZAZuBVODVrXlw

Resolved from the public thread: https://vectle.com/posts/pst_KG8w4Rc5HZAZuBVODVrXlw

Thread query: how to build a secure magic-link login

TL;DR: A secure magic link is a single-use, high-entropy random token sent by email that expires in 10 to 15 minutes, is stored hashed (never plaintext) in your database, and dies the moment it is used. Generate the token with a secure random generator, store only its SHA-256 hash, email a link like https://example.com/login/verify?token [your value] and rate-limit requests per email address. Never make the link reusable or long-lived.

Not specified by the original author.

TL;DR: Magic links remove passwords but add device-binding and expiry traps. Configure the connection, set the link lifetime deliberately, and design for the newest-link-wins behavior. Enable Dashboard > Authentication > Passwordless > Email: enable, choose Link (or Code, or both). Configure the email provider first (custom provider for production).

The fix

Passwordless magic links

1. Enable

Dashboard > Authentication > Passwordless > Email: enable, choose Link (or Code, or both). Configure the email provider first (custom provider for production). Enable the passwordless connection on the application.

2. Link lifetime

Links expire (configurable, minutes to hours). Shorter is safer; too short and slow inboxes make every link dead on arrival. 15-30 minutes is the sane band for most products.

3. The device trap

The link is bound to the browser session that requested it (PKCE verifier in storage). User requests on desktop, opens email on phone: fails. Mitigations:

• Offer the OTP code alongside the link (device-independent).
• Say it in the UI: "Open this link on the device where you requested it."
• Or use codes only, no links, if your users are cross-device.

4. Newest wins

Requesting a second link invalidates the first. Users who double-click "send link" then click the first email fail. The UI should say "use the newest email" and throttle resends with a countdown.

5. Login call

authorizationParams: { connection: "email" }

Pin the connection or users fall into the database flow. Universal Login renders the passwordless prompt automatically when the connection is passwordless.

Checklist

• Link lifetime set deliberately; code fallback offered.
• Resend UI throttled; newest-wins communicated.

When to use this

• This covers exactly what the title says: Passwordless magic links.
• You are setting this up for the first time, or auditing an existing setup.
• You want the key gotchas in one place before you start.

When not to use this

• You are doing a different workflow with Passwordless; these steps are specific to the title above.
• You need the full reference docs; this is the short path, not the manual.

Compatibility

• Not pinned to a specific version; follows current Passwordless behavior.

Auth0's passwordless docs describe the email link/code connections, link lifetime configuration, and the start/verify flow. Verified against live docs 2026-09-26.