Magic links and Passwordless login

I’ve seen a lot more apps ask for just an email for sign up and sign in recently. In some ways this is an awesome alternative to using username + passwords. After spending some time chatting with the development teams, we’ve learned they see it as a low barrier to getting users in, especially since passwords are a bane for users.

Their auth systems usually consist of authN and authZ (for more information check out the article on the difference between these). Their authN is just enter your email. Sweet and quick. Then they’ll use the email or dynamically generated userId as their identifier in their authZ access control.

It’s the quick and easy solution

Seems relatively easy to set up and implement, perhaps a quick database table with userId associations as well as something to generate those magic links to send out.

I like it because I also hate passwords. When you want to invite other users, which is notoriously difficult, you have to use an email or at least share a link. It’s also pretty nice because they can reuse the flow for sign in. Also it frees up the team to not have to worry about a messy password reset flow, one that probably involves copying and entering codes.

Additionally, since the bar is always moving on how to best store passwords, it avoids that nasty business as well. You may see some suggestions on using bcrypt with crypto random salts, that’s actually not even the best solution out there. You may have thought since the brand names use bcrypt, they must be the best. But it turns out that isn’t the case. So unless you follow the latest trends or even using a SaaS solution, you could be in trouble.

So there seems to be a lot going for a passwordless type of solution. Probably the most notable benefit being built-in email verification. That is, no one can fake your email/username when using a site, because it is coupled to another login process.

So why not use it then?

That’s about where the benefits of using email links as login stops being so great though. There are a fair bit of edge cases that come up quite frequently which cause solutions like this to fall apart, when they are the only way to log in.

1. How will you handle multiple logins? Perhaps you are hoping that the email provider let’s users add the email label (adding a + to any email), but how many users know about that sort of functionality?
2. How will you handle changing email addresses? This is one of those cases that will happen, but you hope you’ll never have to deal with it. When a user wants to change their email address, then they should be able to change it. So now you need another complex flow to make that happen. When a user is coupled to a userId generated separately by the user, that’s less of a problem.
3. You also open yourself up to common attack vectors that hackers use, and that is account impersonation. By having only a single string to represent each user, an attacker can continually guess email addresses until they have a hit. From there they can choose who they want to target. When you need both an email/username and a password, you can block requests where either is incorrect.
4. Another common problem is insecure email addresses. What happens when your email provider has a security breach. Account logins now are a huge issue, because each one of those is the login itself. Or what if a user is connected to a vulnerable hotspot and accesses their email in an unsecured way, a link as a login offers its own insecurities. This is the main reason why Oauth2.1 specifically forbids the use of tokens in query strings. Tokens in URLs are not safe.
5. Replay is a huge problem, what happens for a user with multiple tabs or closing and opening, or miss-clicking. The links will have to be one-time use only, but that means, if the user “logs out” and then returns they’ll need to go through the email flow again.
6. You can’t predict every user’s email provider, that means that the user will have to leave your app to log in. They’ll have to access their email provider and click there. If they have tons of emails or in the middle of doing something else it’s easy to have them get lost.
7. Attackers can use your service to send login emails to many different users. You start paying for the resources. If you are using SMS to send those links, then an attacker will cause you to fraudulently send messages to every number they put in.

The next step

Actually logging in via the link side-steps the whole benefit that federated login providers offer, think Log in with Google, Twitter, Facebook, etc…

These providers offer something that other identity providers don’t, and that is MFA through that email login. Taking another step forward from just email, these offer 2FA after password, depending on email links or hardware token validation. And some go even further with security precautions like deviceId checking, IP remembrance, and session tracking, which email can’t use.

But there are many of these, and aggregating the logins across federated login providers is challenging. Forgetting which login strategy you picked and making duplicate accounts is a problem. Or merging two accounts both using the same Google login. To solve this identity aggregation is necessary.

Going further

It’s easy to start with magic links but the challenges start to break down pretty quickly. Additional issues with user session tracking and multiple devices just add to the complexity. And these aren’t something that you want to deal with. That’s even before you have to start worrying about the attack surfaces for your product application.

Start with an Identity Aggregator and solve the complexities with login from the beginning. They make it simple to integrate and provide your application and users the protections they need.