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.
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.
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.
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.
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.