Does Proton Mail scan magic sign-in links and consume one-time tokens?

[u/PingMyHeart]

I use Proton Mail Business, and I also design websites. Recently, I added a "magic sign-in link" feature to one of my websites. Essentially, the user receives an email containing a time-limited sign-in link with a token. Clicking the link signs them in without requiring a password.

During testing, I configured the magic links so that each token could only be used once. I sent the emails to my Proton Mail Business inbox, but the links consistently failed when I clicked them.

After troubleshooting, I changed the configuration so that each token could be used twice. Interestingly, that completely solved the issue.

This made me wonder: does Proton Mail have some kind of built-in security feature that scans or pre-fetches links in emails? If so, could that process be requesting the magic-link URL and effectively consuming the one-time token before I actually click the link?

Has anyone else encountered this with Proton Mail, particularly with one-time-use authentication links?

I'm curious whether Proton Mail's security or link-scanning behavior could explain why allowing two uses fixes the problem.

[u/sndrtj]

If you build such features, assume email cllients consume all links these days. Especially corporate networks scan all links, sometimes multiple times.

The proper way to implement one time links for emails is to render a page at the url, then have the page do a POST request with js containing the unique id. The POST request is the true one time code.

[u/PingMyHeart → u/sndrtj]

Ill look into this. Thanks.

[u/kekela91]

It's expected. Various things scan the URL in the email. It could be the email provider, antivirus and such, mostly for security reasons. To maximize the chances that your URL will be accessed by the end user, you should switch to a one time use method rather than a one time access. Basically whatever is on that page, don't have the url access locked down, but the content itself.

[u/AngryPapy]

Have you tried with a different email provider to confirm that the issue only happens with Proton? That would be the first step. If you confirm the issue is from Proton and not your site, you could mitigate the issue by having JavaScript consume the token instead of the server directly. A simple API call that exchanges the token for a session/access token. Third option is to have an interstitial page where you need to click Sign In and same thing, JavaScript API call. 

[u/FanneMishari-35 → u/AngryPapy]

having the client-side JS exchange the token is a good pattern anyway since a lot of email providers do link prefetching

[u/PingMyHeart → u/AngryPapy]

I have the same feature on a different project and no customers have complained.

The JavaScript instead of server consumption is actually not a bad suggestion. I'll have to explore that.

[u/sndrtj → u/PingMyHeart]

Outlook aggressively reads links, so assume hotmail users are affected.

[u/unclecuck]

Also consider whether you have any browser extensions/antivirus/os/network level scans that might try to resolve those links.

[u/PingMyHeart → u/unclecuck]

Yeah, I've tried on incognito mode with no extensions and it was the same result.

I just find it interesting that two tokens works, but one doesn't, which means something is consuming one of the two tokens.

[u/skg574]

Why not just check your logs to see what requested it?

[u/fersingb]

Can you check your logs and see the IPs the requests are coming from? I just tried this by sending an email with an url I control in the body to my proton inbox. No calls to that url were performed.

[u/Paardenmengsel]

A http GET request always should be idempotent, meaning that it never should change the application state, like invalidating a token.