I'm developing a mobile app (side project) and as usual, I'm thinking about user authentication. I've been wondering for a while if logging in with a link in an e-mail is a secure solution. It's not something new. I have seen several services that have implemented this login method, like Slack or Medium. Passwordless is also supported by popular authentication services like Firebase Auth, Auth0 and Magic.
Let's think about advantages.
In theory, implementing passwordless login is more straightforward than the other options. You don't need to store the password in a database or support the password reset option. The user provides an e-mail and clicks on the link. You need to verify the token and authenticate the user. Less backend/frontend work and even less testing.
Users don't need to create a password, remember it or use any password manager.
It's one field less in the login/registration form. The user needs to provide only an e-mail address to log in or create an account.
I like how the Magic links work because a user can click on the link on any device. Let's say I want to log in using someone else's computer. I would need to get my phone, open a password manager and type a very long password. Using Magic links, I can click on the link from my phone. It's much simpler.
What about disadvantages?
It’s something new for users and they can be lost. It's not a big issue, but all users are used to passwords. New options can always confuse some users.
A similar situation is when you decide to have a single page and the same form for login and registration. Users can be confused.
Everyone knows how to use passwords.
E-mail may end up in a spam folder and from my experience, most users don't check it or even don't know it exists. Of course, the same can happen with an e-mail to confirm registration or with a password reset, but you need to register once and you don't use the password reset function very often. You will need the e-mail more often when you use passwordless authentication. You can try to prevent an e-mail from ending up in a spam folder, but it can happen.
E-mail can have some delivery delay. What if I need to log in and the e-mail comes 15 minutes later? What if the token is valid only for 10 minutes? I know, usually, the e-mails are delivered very fast, but it can happen, right? It can be an issue with a user e-mail provider, with e-mail service you use for sending e-mails, network issues, etc.
I know it's unlikely to happen, but it's possible. If your authentication method allows you to open the link on any device (like Magic), someone can submit any e-mail address and wait for action. Users can click on the link by accident and give somebody unauthorized access to their account.
It is unlikely to happen with the e-mail/password method.
Let's say a user loses an access to his e-mail account or address. There can be many reasons for this: forgotten password and no possibility of recovering account, blocked account, expired domain, or e-mail provider's problems. If you do not have access to your account, it means that you can't log in. It's not an issue when you use e-mail/password method because you can log in using your password and set the new e-mail address.
Usually, the link should be opened on the same device. What if a user wants to log in on a device where the e-mail is not configured? I know we can open the mail using a web browser, click on the link, log out and validate that the password is not stored in a (browser) password manager but it’s an additional step.
Users should be aware that the link should be opened on the same device. If you want to login in on your mobile phone and click on the link on the desktop, it won't work. The link will expire and the user will need to log in once again to get a new link.
It can happen to someone who doesn't know how it works or doesn't read what needs to be done. Assuming the website displays the appropriate message.
Let's say you want to use Firefox on iOS to log in to the website and your default browser is set to Safari. You can go to the e-mail client and click the link. It will open the Safari browser and the login will fail because it needs to be opened in Firefox. You will need to fill the e-mail form again, go to an e-mail client, copy the link and open it in Firefox.
It's a tiny problem, but it does exist. Whenever you click on the passwordless authentication link, it will open a new tab in a browser. You will need to close it manually.
You need to open your e-mail client to log in, every time. It’s more work than automatic form filling using a password manager.
Users may forget which e-mail address they used to log in. Using another e-mail address may create a new account.
It's not an issue with e-mail/password method. The login form usually displays a message that the account does not exist or that a password is not correct.
It's similar to the previous point. If a user makes a typo in the e-mail, it will create a new account and the user will not receive a login link.
Sending a magic link assumes that the user e-mail account is secure. The issue is that you can't be sure. Using an e-mail/password method, you can force a password length and format, periodically ask for a password reset, add 2FA (have you seen passwordless log in with 2FA?), track password leaks, etc. Using magic links, you leave all of this for the user e-mail provider.
Users may need a lot of support. I read somewhere that using magic links decreases the number of support requests related to password reset. It may be true because the passwordless method does not require it but it can create new issues. What can you do when a user lost access to the e-mail account? What if a user has forgotten which e-mail address he used? What if the e-mail did not arrive? A typo? Spam? E-mail service issue?
I'm not sure about it and I can't find any example but I heard some time ago that some spam/phishing/security systems on e-mail provider side were clicking on links from e-mails to test them. In this case, the link may expire until you click on it.
As I said, I like the idea but the number of disadvantages discourages me from implementing this method. The standard e-mail/password method seems to be more secure and may be easier to support.
What's your opinion?