[pritambaral]

> Mobile email clients use their own browser and cookie jar which consume the session cookie you're trying to put into the user's main browser. This results in users 'never staying signed in' and a lot of frustration.

The earliest Magic Links I remember using didn't have this problem, and this was before smartphones. The Link, back then at least, was only to authenticate that you can receive emails at a certain mailbox, not to authenticate whichever browser you used to open it. Your login attempt would keep the login (not logged-in) session open wherever you attempted to login from, while waiting for the Magic Link to be clicked on in the background. Whenever the Magic Link was clicked, irrespective of where it was clicked, your original browser session would stop waiting and log you in.

This also avoids the tedium of having to copy a link or code from one device/app to another. Just click, a browser tab/window opens for a short time, and then closes automatically after doing its job; you go back to wherever you attempted to log in, and simply proceed. This also simplifies post-login flows (like visiting a specific page you tried to access before being forced to login) in that such flows don't need to be tied to the Magic Link itself.

[londons_explore]

You have to deal with 'email antivirus scanners' which click every link in a mail sent to every user in some sandboxed browser.

If your user has one of those, then their account effectively has zero security since an attacker can attempt to log in, and the web security software will click the link, and the attacker (in the originating browser) is now logged in.

[bombcar]

Those destroy the links anyway; I can never reset a Salesforce password because the link is always “expired”.

[SkeuomorphicBee]

That seems extremely unsafe, email being what email is, there are many layers of automation that may access that link unprompted: a spam/virus filter on the server or the client may access it to verify it is not some malware, a email client may access it to preload assets, etc. So if a malicious actor starts a login on one of my accounts, and somewhere along my email chain-of-custody/stack a helpful software access that link for some reason, then the malicious actor will be authenticated.

[yesbabyyes]

A site could mitigate this by responding with a form to be posted, asking the user to click a button to verify. Only the POST request after user interaction would verify the email address.

[daveoc64]

I think this is an important point that is often overlooked.

I can quickly access email on my phone - that doesn't necessarily mean I want to log in on my phone.

[IggleSniggle]

As a user the problem I run into with some frequency is passwordless login where the waiting session loses its “waiting” status because I switched the active application in iOS from my browser to my email and back again. When I get back, the page for whatever reason (refresh after being backgrounded?) requires a new auth attempt.

A wrinkle in this complaint is that in most scenarios I don’t especially want a browser tab to be able to hold onto a persistent session while it’s closed due to privacy reasons, regardless of where that session state is held (and I realize there are a number of options).

[londons_explore]

> (refresh after being backgrounded?)

This is a problem on low memory devices - the page gets forced to refresh because the system ran out of RAM. The iPhone 13 only has 4GB of RAM, and with many apps requiring 2+GB, it is frequent a web page can't stay loaded in the background.

Most android devices have 8GB plus RAM, so shouldn't hit that issue, although it still happens on very low end devices.

[IggleSniggle]

They can take my iPhone 7 and its 2GB of RAM over its dead body.

[pritambaral]

This took me a bit of time to realise, but well-designed software can avoid this problem rather simply: Combine the Magic Link with a short-code that can be manually typed into the browser session attempting to login. This short-code can then be prominently displayed in the email header and/or early on in the email body, so a user can simply read it off the notification that the email would generate. No need to switch apps from browser to email.

[couchand]

A simple workaround for the implementation is to redirect you to a URL with the code hashed as a query parameter.

[IggleSniggle]

Yes, I was thinking about that, as something like a TOTP. But that needs to be done via DNS-over-HTTPS or DNS-over-TLS or else the code can be sniffed by a MITM since the URL is sent in the clear, at which point you’re back to the problem of persistent TLS anyway.

Edit: In fact, nevermind. My thinking on that was flawed. I think you’re right, that should be fine, as long as the DNS is encrypted.

[ncallaway]

I just recently implemented a magic link flow for a project I’m working on, and “authenticated in the originating browser” was a high priority item for me.

I think it’s just so much nicer of an experience to not have to worry where you go check the email or which browser opens when you click the link there.

The site you used to login was clearly where you intended to be, so that should definitely be one of the authenticated sessions when you click the link.

[thdxr]

The issue I ran into with this was I could initiate a login for anyone and if they accidentally hit the link I could remote login.

Switched to pin code entry, less fancy but achieves all the desired UX

[ncallaway]

I think that’s totally fair. The site I’m working on is pretty low stakes from a security perspective (a private personal blog), with less technical people in the audience, so I was willing to make that trade off for the UX outcome I wanted, but that was specific to the damage of a breach in my specific use case.

[RulerOf]

>Your login attempt would keep the login (not logged-in) session open wherever you attempted to login from

While I generally agree that this behavior is correct from a usability standpoint, it's not safe. That design allows a user to do a one-click account compromise when they receive a magic link that was sent in response to the login attempt of an attacker that happened to know the user's email address.

[silversmith]

So add a step that requires "knowledge transfer" between the login device and confirmation device. Microsoft does this in their authenticator app showing essentially three confirmation buttons with different numbers on them, and requiring you to press the one being shown on the login screen. Worst case you now have one-in-three-clicks account compromise rater than one-click. And hopefully this also causes the user to ask why they are being required to log in if the app is not displaying the confirmation data.