[r2b2]

To somewhat mitigate the link-loading bot issue, the link can land on a "confirm sign in" page with a button the user must click to trigger the POST request that completes authentication.

Another way to mitigate this issue is to store a secret in the browser that initiated the link-request (Ex. local storage). However, this can easily break in situations like private mode, where a new tab/window is opened without access to the same session storage.

An alternative to the in-browser-secret, is doing a browser fingerprint match. If the browser that opens the link doesn't match the fingerprint of the browser that requested the link, then fail authentication. This also has pitfalls.

Unfortunately, if your threat model requires blocking bots that click too, your likely stuck adding some semblance of a second factor (pin/password, bio metric, hardware key, etc.).

In any case, when using link-only authentication, best to at least put sensitive user operations (payments, PII, etc.) behind a second factor at the time of operation.

[klabb3]

> a button the user must click

Makes sense. No action until the user clicks something on the page. One extra step but better than having “helpful bots” wreak havoc.

> to store a secret in the browser […] is doing a browser fingerprint match

I get the idea but I really dislike this. Assuming the user will use the same device or browser is an anti-pattern that causes problems with people especially while crossing the mobile-desktop boundary. Generally any web functionality shouldn’t be browser dependent. Especially hidden state like that..

[r2b2]

I agree, better to use an additional factor than fingerprinting.

[eadmund]

> Another way to mitigate this issue is to store a secret in the browser that initiated the link-request (Ex. local storage).

Or just a cookie …

But this approach breaks anyway in cases such as a user on a desktop who checks his email on his phone for the confirmation.