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.

Fundamentally, you will have to deal with these issues:

1. Your links will expire and users will still click them, the resultant experience will be bad for them.
2. Attackers will attempt to abuse your magic links to do email validation.
3. Attackers will attempt to abuse your magic links for beg-bounties.
4. Attackers will attempt to abuse your magic links for fun.
5. OTP via email is phishable. Email links are also phishable if those links enable cross device log in flows. If the link must be resolved on the same browser/tab that the login was started in, these are less-phishable.
6. Email scanners that check for spam and malicious emails automatically click links in your emails. This will include your one time login links. Thy can and will definitely interfere here.
7. The entire flow is significantly worse UX than every other log in strategy (sans passwords), the fact is, users need to separately go to their email and there is no way to deep link to that email. Now you can optimize a little bit by guessing their email provider and hot linking to it to open that email, but this only works for quite the pittance of email providers. Using this Email-Linker significantly improves the UX, but still is limited.
8. Network connections are not perfectly reliable. Which means your users will attempt to use a valid code via the link, the connection will be dropped mid exchange causing the code to be marked as used, but the user won't have received a valid access token/auth cookie/etc from you.
9. Email access flows are susceptible to MITM attacks unless the originating application uses some sort of PKCE to ensure closed loop auth to the originated trusted application. However this directly breaks multi-device flows, and users with multi-device expectations will click on the these links and have a bad time.
10. These emails will eventually end up in spam for someone, so you'll still need to support a first class auth strategy.

The next step

Actually logging in via the link side-steps the whole benefit that federated login providers offer, think Log in with Google, Office 365, Twitter, 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.