I'm mildly surprised that one of your complaints is that these fill your email. It seems simple enough to delete them?
Once I click the link, it takes me away from my email inbox. That means I have to go back and clean them up later. That's extra work for something that should be ephemeral. No thanks. I can't quite put my finger on why it's different from having SMS 2FA codes in my Signal inbox, but it feels like more clutter.
SMS clutter is worse for me. Harder to delete in bulk.
MagicLinks are a mobile nightmare. 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. Sending a one-time code via email fixes this, and is in practice about as easy to use as a link on desktop. In our app (Loomio) we default to magic/codes, but let users…
> 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 mailb…
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.
> 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 mailb…
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…
> (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.
MagicLinks are a mobile nightmare. 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. Sending a one-time code via email fixes this, and is in practice about as easy to use as a link on desktop. In our app (Loomio) we default to magic/codes, but let users…
> 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 mailb…
>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.
I hate them. Force me to go to my mailbox while I have a good password manager and just want to use that instead. I get the idea, but this should be an alternative, not a default. Also sends loads of single use emails that will remain for ever in users mailboxes.
They should be the default because they are more secure than a password plus a email password reset.
MagicLinks are a mobile nightmare. 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. Sending a one-time code via email fixes this, and is in practice about as easy to use as a link on desktop. In our app (Loomio) we default to magic/codes, but let users…
> MagicLinks are a mobile nightmare. 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. It might be howling into the void but the conclusion I reach from this is that "Mobile email clients are a nightmare". Generally speaking, embedded browsers in mobile apps are a terrible idea and break user expectations in multiple ways.
On the flip side, I find that opening links in isolated sessions very valuable, if not just because I don't want links sent by others to affect the Algorithm's perception of me. 80% of the time, I want to be a blank slate when interacting with in-app browsers.
> 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 mailb…
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.
Those destroy the links anyway; I can never reset a Salesforce password because the link is always “expired”.
MagicLinks are a mobile nightmare. 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. Sending a one-time code via email fixes this, and is in practice about as easy to use as a link on desktop. In our app (Loomio) we default to magic/codes, but let users…
> 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 mailb…
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.
The magic link is basically using "forgot my password" e-mail recovery flow to just friggin' log in. If you've served the user a link which takes them to a session where they can change their password, that session must be authenticated, by definition; you would not allow an unauthenticated visitor to change an account password! And so, if that password change session is authenticated, then just treat that as fully f…
Many of my accounts I use the password reset feature then enter a long and secure password and never store the password. Next time I log in I reset my password again.