[ajanuary]

Two problems I’ve encountered with magic links:

* Mobile email clients that open links in an embedded browser. This confuses some people. From their perspective they never stay logged in, because every time they open their regular browser they don’t have a session (because it was created in the embedded browser) and have to request a login link again.

* Some people don’t have their email on the device they want to log in on.

Sending codes solves both of these problems (but then has the issues described in the article, and both share all the problems with sending emails)

[sweetjuly]

Magic links can be used to authorize the session rather than the device. That is, starting the sign in process on your laptop and clicking the link on your phone would authorize your laptop's sign in request rather than your phone's browser. It requires a bit more effort but it's not especially difficult to do.

[johtso]

Wouldn't that be incredibly insecure? Attacker would just need to initiate a login, and if the user happens to click the link they've just given the attacker access to their account..

The reason why magic links don't usually work across devices/browsers is to be sure that _whoever clicks the link_ is given access, and not necessarily whoever initiated the login process (who could be a bad actor)

[dspillett]

> Wouldn't that be incredibly insecure?

If done naively with a simple magic link, yes.

> and if the user happens to click the link they've just given the attacker access to their account

Worse: if the user's UA “clicks the link” by making the GET request to generate a preview. The user might not even have opened the message for this to happen.

> Wouldn't that be incredibly insecure?

It can be mitigated somewhat by making the magic link go to a page that invites the user to click something that sends a post request. In theory the preview loophole might come into play here if the UA tries to be really clever, but I doubt this will happen.

Another option is to give the user the option to transfer the session to the originating UA, or stay where they are, if you detect that a different UA is used to open the magic link, but you'd have to be carful wording this so as to not confuse many users.

[Hackbraten]

> Worse: if the user's UA “clicks the link” by making the GET request to generate a preview.

You mean something like a popover preview that appears when the user hovers over a link?

Isn’t there a way to configure the `a` element so the UA knows that it shouldn’t do that?

[dspillett]

> You mean something like a popover preview

That, or a background process that visits links to check for malware before the user even sees the message.

> Isn’t there a way to configure the `a` element so the UA knows that it shouldn’t do that?

If sending just HTML you could include rel="nofollow" in the a tag to discourage such things, bit there is no way of enforcing that and no way of including it at all if you are sending plain text messages. This has been a problem for single-use links of various types also. So yes, but not reliably so effectively no.

[xx_ns]

And we get back to the original point of the article (sort of). Opening a magic link should authenticate the user who opened the magic link, not the attacker who made the application send the magic link.

[KayEss]

This is what makes securing this stuff so hard when you don't have proper review. What seems like a good idea from one perspective opens up another gaping hole somewhere else.

Off the cuff suggestions for improving UX in secure flows just make things worse.