[sborsje]

There's a near-infinite amount of not-so-small gotchas when implementing magic links:

- If magic links are the only way to sign in, authentication success rate is now directly tied to your email deliverability rate.

- Single-use tokens (immediately expiring after clicking) can be followed by spam filters, and thus immediately become invalid for the actual user trying to sign in.

- MTAs using greylisting can cause unexpected delays in email delivery.

- If a session audit trail is implemented, malware scanners following links might cause sessions from unexpected locations showing up.

etc.

[matsemann]

Also, they only work if I have an e-mail client on the device I'm trying to log in from. Otherwise having to transfer this link becomes a burden.

Additionally, even if I do have the e-mail on my device, clicking the link on mobile often opens it up inside some alternative web-view. Thus the session is tied to my e-mail client, not my actual browser.

[pritambaral]

This wouldn't be a problem if the Magic Link was used only to authenticate your original login session, and not to start a new session wherever it was opened. Like I mention here: https://news.ycombinator.com/item?id=32081608

[timwis]

Great points! The deliverability (and delay) issue is the one I’ve found most challenging. For the others, here are some mitigations I’ve come across:

- instead of single use tokens, set them to expire within 60 mins

- to prevent spam/malware checkers signing in when following the links, have the magic link take you to a page with a sign in button to ‘complete’ the sign in process. And, optionally, add some JS that clicks it for you on page load. This is the same approach used for unsubscribe links.