I would like to remind you all that email is an unsafe medium. You’re not sending electronic letters, you’re sending electronic postcards.
When you send a ‘forgot password’ email, it can normally only be used to reset a password once. On top of that, the better services also time these links out after a few hours.

With magic links, people will get grumpy if you time their old link out, so all old links should continue working for a very long time.

But in both cases, I have the feeling that too much trust is put in the medium that is email. But solving this problem is a bit a chicken-and-egg problem, as techniques like PGP are somewhat of a hassle to set up and need a password themselves.

fyi I updated the article incorporating your idea and mentioning this thread – thanks again!

Nice post!

A feedback (or more like a question): from a security point of view, would it be better not to let the user know whether or not the email is found on the DB? Just notify the user as if the email were successfully sent, but silently swallow the error on the server-side (you don’t actually send the email). That way any potential attacker wouldn’t be able to guess who’s registered on your system.

UX-wise it would pose a problem if the user mistype their email, but that can be circumvented by just printing back the email to the client (“We have sent a magic login link to foo@bar.com. See you soon!”).

But of course implementing it this way doesn’t mean you can left out the maximum number of tries validation (and possibly captchas) for preventing brute-force attacks and using your system as spam mail generator

Thanks for the tutorial, I’m still trying to work out whether I want to use this in my app, for the following reasons:

1. Is it easier for most people to check email to sign-in each time (or am I missing something)?

2. Is it significantly more secure - to save user profiles etc, a user account still needs to be created and checked against for creating sessions between logins, which will always have some login info stored eg email address if not password?

3. Is there a better way - eg as much as a developer may prefer not to use it, is signing in via Facebook etc the more practical version of passwordless authentication?

Perhaps, giving the user a choice to do one or the other or both would be best - log in by email link or password, whichever is most convenient at the time?

I think we might leave the actual intent of the article/guide: Of course there are considerations, trade-offs etc. involved, as its the case with any kind of authentication.

My goal was neither to propose passwordless authentication as the one-size fits all or best solution nor to give an overview of all available options and compare them. The guide is for people who decided that passwordless auth is a good fit for their case or that are considering it and would like to see what a potential implementation might look like. I hope it helps these people to decide whether or not it might be a good solution – maybe also as a supplement to other kinds of authentication.

There are lots of good resources out there for comparing the available options and a few of them are linked in the article.