Hacker News Reader

Comment by sieabahlpark | Hacker News Reader

I personally just really don't like magic links auth. It just feels brittle and if your email provider attempts to scan urls to see where they actually go you end up giving them an auth token and by the time the user clicks the link it's invalidated (or you don't invalidate the link at all which is worse).

If you have an issue with bots on your platform you're going to always have bot problems. It's trivial to abuse your auth to derank your standing too. I can force your app to send out bounced emails to hundreds and thousands of bad emails. Costing you $$ or rep in the email exchange. The second affects your ability to authenticate legitimate users too.

Wish magic links would just go away and be acknowledged as an anti-pattern.

View on HN

> It just feels brittle and if your email provider attempts to scan urls to see where they actually go you end up giving them an auth token and by the time the user clicks the link it's invalidated (or you don't invalidate the link at all which is worse).

At my current employer (an auth vendor) we ended up changing our magic link behavior to require a post from the user to log in because of this issue (the scanners didn't get an auth token, but they did invalidate the one-time code and confuse end users to no end.

If you want more details, there is some discussion here: https://github.com/FusionAuth/fusionauth-issues/issues/2443 and on the related issues.

> if your email provider attempts to scan urls to see where they actually go you end up giving them an auth token

This is what the "change the temporary token for a "permanent" token they (the frontend) can use for authentication" part is for, as it'll require a browser to visit the page so the token can be set in the frontend after making the "switch" with the authentication backend. The tokens get invalidated when used.

Regarding abuse, there is a lot of other things around the design itself that has to be considered that I didn't mention. Rate-limits, validation, verification, operations and other things feel kind of besides the meat of the pattern. Otherwise we'll end up with very long comments :)

> if your email provider attempts to scan urls to see where they actually go you end up giving them an auth token

One way you can handle this is to place the token in the hash portion of the url (which doesn't get sent to servers during an HTTP request), and then have JS on the frontend send the token to your backend manually. As long as the email provider isn't scanning links via a headless browser that executes JS, this should work.

I agree with your point about email abuse though (although you still have to prevent bots from abusing email based password resets).

For some prior art, Okta avoids the email link scanning issue by requiring "same browser, same device" (sessions) [1]. An OTP code is included in the email as a fallback for users receiving mail on a different device than they're trying to log in to.

[1]: https://developer.okta.com/docs/guides/email-magic-links-ove...

Reply on news.ycombinator.com