And even if simple enough it relies a lot on cookies to avoid the hassle of the flow and become absolute crap when using private session or a cookie cleaner.
For the "personal project where security isn’t critical" use-case half the time the site would be better without authentication and the other half I'll probably use my default crapshot password because it's not worth more effort.
Edit: on the dev part it's not even simpler than a password solution since in the example the token is stored server-side and you still need to send emails. If you don't care about session invalidation then you could just rely on the token with a bit of encryption/hashing.
Another edit: you could probably just add an optional password field to the flow and obtain something more flexible for the user without adding much complexity.
-> When creating an account not much diff
-> When logging if you have the correct password then great otherwise send the token
-> When entering the token add optional password to update
My email is already synced. There is no extra work.
> they'll be locked into a single browser on that device?
I don't know where you saw this conclusion from. Their are multi-browser password managers and you can always copy+paste.
It's different because it is already done. I don't know of anyone who hasn't already set up their email on all their devices.
Literally, not a single person I know that has a desktop, laptop, tablet and/or phone or any combination of the above that hasn't already got their email on their devices working.
Maybe you use a computing device that doesn't already receive your email, but you're in a minority.
Is synchronisation a problem? 1Password does it all for me, I don't even notice it.
It is for me. I use a command line password manager using the `pass` tool. I choose not to use any browser extensions or sync these passwords in a way where they leave my main workstation.
It's really inconvenient when I need to use my phone to login to some site. It involves manually typing in some password that looks like this: aC6)&hahi*`9$Ik+WU7xA[igDfw\w'"VC_^VKh{<|PU~EQb{. You have any idea how tedious that is to do on a phone, especially when the site doesn't offer a way to see the password with a toggle? :D, on my workstation my password manager copies it to my clipboard for a short period of time so there's no typing involved.
Magic links solve this problem because all I have to do is be logged into my email account to be able to access any site that uses magic links.
Personally I have my email password remembered, I don't sync anything between my workstation and phone such as browser accounts or anything like that.
All I know is, logging into a site using a magic link on a phone for me is much easier since all I have to do is check my email and click a link instead of typing a ~50 character randomly generated password that I made on my workstation when using the site originally.
If someone already has access to my email then it's game over.
An hour should be ample time for it to be delivered while offering a decent amount of security around token availability, especially since it should be revoked as soon as it's been used once.
Both of those are a worse UX than either using a password (with constraints enforced by the site) or email-based auth.
> 1. The browser will generate all your passwords. The UX to pick your own password will be awkward.
So, not only will the user be locked into a single device, they'll be locked into a single browser on that device? That's hardly an improvement, is it?