The link is a "safe" GET request. The page loaded via the link should do an "unsafe" POST for the login, via javascript with a form button for fallback.

https://www.rfc-editor.org/rfc/rfc7231#section-4.2.1

>The purpose of distinguishing between safe and unsafe methods is to allow automated retrieval processes (spiders) and cache performance optimization (pre-fetching) to work without fear of causing harm. In addition, it allows a user agent to apply appropriate constraints on the automated use of unsafe methods when processing potentially untrusted content.

Exactly the same for email unsubscribe links, or a one click "buy now" link.

If you want to do this without JS just add a page with a "Click here to complete login" button that does the POST.

Automatic link pre-fetchers know JavaScript too and will trigger your JavaScript to post.

I've had to implement a system where if the link was minted x minutes ago, the JavaScript on the landing page is disabled.

It's just another arms race. It shouldn't be this hard, but in email it seems everything is additionally harder to do.

Why not just have a username & password. Why make everything so complicated? We just successfully got password managers deployed to most users, only to drop passwords entirely for a subpar system?

One example is an unsubscribe link. Legally, it would be no bueno to have it behind any sort of login.

Another is just counting if a link from an email was clicked. I want friction to be as little as possible. That's done by having some sort of redirect, but you have to use a JavaScript initiated post to weed add false positives. That's already ridiculous, but because of automated link prefetchers, you still need to disable that and show a f'n button.

And then I have to answer to clients that want to know why their clickthrough stats are down precipitously and I don't honestly have the wherewithall to explain the inner workers of every filter that snoops their email before they read it.

> We just successfully got password managers deployed to most users

Source?

Every desktop and mobile OS has a built-in password manager perfectly adequate for this use case, with encrypted sync and backup capabilities.

In my app, I just added an “Almost there!” Page with a button that the user needs to click. I still need to add a fallback option that uses a one time code for the other reasons mentioned above.

Save a browser cookie when the login is initiated. When the link is clicked check if the same cookie is present. If not, ignore it. Expire the link and the cookie after n minutes.

Surely this breaks the "email is not on same device as login" use case? At least with normal magic links, they're merely incredibly annoying but doable (via e.g. typing in the URL)

That use case still works. In fact it works better because if you click the link on your phone you don't automatically get logged in on your phone browser (or your email client's in-app browser). You can then copy the same link on your desktop and it will work as expected.

I'm confused. How do you get the cookie from the original device to the other device?

It's the other way around. You copy the URL to the device that has the cookie.

How do you copy the link between devices? QR code?

As long as you also have a code to enter, then things will feel fine across devices.

After reading the other replies, this seems like one of the more effective approaches. Thanks!

Using a time-based expiration rather than a usage-based expiration should help

E.g. require to click a button to actually sign in, don't consume the token and establish the session on mere URL access.