Passwordless Authentication: Which Option Is Right for Your App

Password-based authentication systems are prone to various cyberattacks, including brute-force methods, phishing, and keylogging. In 2021, over two billion passwords were leaked by attackers. The number of stolen passwords has increased by more than 35 percent in recent years, proving how insecure password-based systems are (hint: something passwordless authentication can help with).

Even though applications encourage users to change passwords regularly and use complex and hard-to-guess phrases, it's inconvenient for users. Most users tend to choose a password that's easy to remember and, therefore, less secure.

This is where passwordless authentication can help. Passwordless authentication is the process of authenticating without needing to input a password or any memorized secret to gain access, in turn reducing data breaches. According to Verizon's Data Breach Investigations Report (DBIR), over 80 percent of data breaches happen due to stolen or weak passwords.

Passwordless authentication systems come in several different types, including biometric authentication, one-time passcodes, magic links, and social logins; and each has its own advantages and disadvantages. For instance, if you have a web application, biometric authentication or USB-based authentication might not be the best system since you'll need external devices for verification. In such cases, other authentication types, like social logins or magic links, make more sense.

In this roundup, you'll learn about different types of passwordless authentication that are currently available. You'll look at these options and compare them based on their well-supported standards, convenience, security, and promising new technologies.

As mentioned previously, passwordless authentication can mean using either a one-time passcode, magic link, or physical hard disk to give you access to the application. In the following section, you'll learn about different types of passwordless authentication, including their advantages and disadvantages.

Magic links are currently a popular passwordless authentication approach that generates a one-time link and sends it to the user. If the link token verifies with the token stored in the database, the user gets access to the application. The basic workflow looks like this:

In this workflow, a user may enter their email, username, or any specific identifier. The application generates and stores tokens if the user exists on the database and sends a link to the user's email. When the user opens the magic link, the token retrieved from the link gets verified with the backend, and if the token matches, the user gains access to the application. The link stays valid for a specific amount of time, and a user will need to request a new link if it doesn't get authenticated within the allotted time frame.

This workflow may sound simple, but behind the scenes, several complex tasks are happening to ensure that an attacker can be prevented from maliciously accessing the links.

When users need to log in infrequently, magic links provide a frictionless experience that leads to a better user experience. In addition, since no password is stored in a database, there's no chance of a password breach, and the risk of a data breach is also reduced significantly.

On average, an enterprise spends $70 USD per password reset. Large organizations in the US allocate almost a million dollars yearly for password-related support costs. With magic links, since no password is attached to the authentication system, there is no need to implement a password-reset solution or a support team.

Even though magic links provide significant benefits, there are also some dependency issues to take into consideration. For instance, if the user's email account gets compromised, the attacker can easily access all applications that authenticate with magic links and use the compromised email to gain access.

With magic links, you also have to worry about email deliverability. Since magic links depend on the user's email, if the email provider is down or the mailbox storage is full, the magic link will not be delivered. In this case, the user won't be able to log in until the mailbox is cleared or the email provider is up again.

In addition, large business-to-business (B2B) companies tend to filter their incoming emails strongly. That means it's possible that a magic link may land in a user's spam folder and affect the overall user experience.

If your application is smaller in size and the frequency of login is fewer, magic link authentication can benefit you. But if a large set audience uses your application and it's essential to efficiently log into the application, you should provide multiple authentication options, like a social login or a password-based login, along with magic links.

One-time password (OTP) authentication is another type of authentication that many modern applications use. This type of authentication sends a passcode (primarily numeric) to the user's registered email or mobile phone. After sending the passcode, the application then asks for the passcode. If the user provides the correct passcode, they can access the application.

OTPs are time-based (just like magic links), and they stay valid for a particular amount of time. After that time frame, a new OTP will need to be generated if the user wants access to the application.

A replay attack is a form of network attack in which legitimate data transmission is purposefully or fraudulently duplicated or delayed. Since no password is required in OTP-based authentication and a new OTP is required every time you log in, this type of authentication is safe from replay attacks.

In addition, because OTP-based authentication is provided by most authentication service providers, it's easy to adopt using an authentication service provider like Clerk. And since no password is involved in authenticating a user, the user doesn't have to remember a password, creating a better user experience.

One of the cons of using OTP is that the messages sent to mobile phones are unencrypted. If the phone or the email address gets compromised, an attacker can easily access the application with the user's profile.

You're also dependent on the network when using OTP. Mobile phone networks might not be stable everywhere and if there's a mobile network issue, the passcode may not get delivered to the user. This can also occur with email if the email provider is down.

Another drawback is that you have to share your mobile number with the application you use. This might be inconvenient and cause issues if your bank account is linked to the same number. Moreover, the provider might call or send the user spam messages; in addition, there is the risk of a data leak. If an attacker gets access to the database, the mobile numbers of all customers can get breached.

The issues with email OTP are similar to the problems associated with magic links. Overall, OTP-based authentication has a few drawbacks, which can be an issue considering there's only one layer of protection. However, your application can be heavily secured using OTP-based authentication as a second layer. For example, with password-based authentication, the chance of getting hacked will be significantly reduced if you integrate OTP as well.

Social login or social sign-in is a type of login where the user logs in with an existing social account. For example, users can use their Google or Facebook credentials to log into an application, simplifying the login process.

One of the benefits of the social sign-in is that the user doesn't have to fill out a registration form and enter details manually. Instead, when registering with a social sign-in, the necessary details are fetched from the social account. This creates a better user experience.

Another benefit of the social login is that the application can collect more information about the user. This information can be used to provide a better and more personalized experience. In addition, using a social login with familiar login identities helps the user perform login efficiently. Users are already familiar with services like Facebook, Google, and GitHub. Seeing a familiar logo and logging in with the social credentials help the user log in quickly.

One of the disadvantages of the social login is the lack of trust. If users don't trust your application, they might hesitate to share their social details.

In addition, if your application uses social login, then you give the user's control to a third party. If the social platform decides to shut its service or something else happens, your users won't be able to log into your application.

There's also a chance that the user is not providing accurate information on their social profile. In such a case, the application will receive false information about the user, which can lead to a poor user experience.

Social logins can provide a great solution if your application depends heavily on user customization. The data received from the social platform will be helpful for creating a custom experience. But this depends on the niche of your application. If your application is built for more professionals or older adults, this login solution might not be the right solution for your users. However, you could combine a social login with a traditional login system, and you can let the user decide which solution they prefer.

The World Wide Web Consortium (W3C) and FIDO published the WebAuthn standard in 2016. It's a technology that focuses on securing private information. Rather than using a traditional password-based authentication system, WebAuthn uses asymmetric cryptography to secure a user's account.

When a user tries to log into your application, the server sends a challenge to the user. After completing the challenge, the user can access the application. The challenge can be solved by the server's approved method. Most of the browsers and operating systems are building native support for WebAuthn. You can see how WebAuthn works from their official site.

One of the benefits of WebAuthn is its native support. WebAuthn continues to gain popularity, which means browsers and operating systems are continuously trying to provide native support. API and JavaScript functions (on most major browsers) are also available using WebAuthn.

Because WebAuthn uses public and private key encryption, it's more secure than a traditional password-based system. WebAuthn also doesn't require any password, and because of this, the chance of phishing or man-in-the-middle attack is reduced significantly.

One of the disadvantages of WebAuthn is the lack of currently available support. Because the WebAuthn authentication system is new, not every browser or operating system natively supports it. However, this is rapidly changing, as most modern browsers are integrating the WebAuthn API.

WebAuthn can also be used with hardware authenticators like YubiKey. But in such a case, if the device gets stolen or lost, the recovery might be tricky if there is no proper setup implemented. In addition, because WebAuthn is in a very primitive stage, the user experience of using WebAuthn is lacking and, at times, can feel too technical to use.

WebAuthn is an excellent alternative to traditional systems, but implementing it for a simple and small application might be overkill. It's ideal for large-scale applications that focus on privacy.

Security Assertion Markup Language (SAML) is an XML-based open standard that transfers data between two parties. You can access all other services linked to your identity by logging into only one platform or dashboard. SAML transfers data between an identity provider and a service provider. The identity provider provides the user's identity and authorizes the service provider. The service provider, based on the identity provider, grants access to the user for the service.

SAML is primarily used in B2B use cases. For example, your company email might let you log into a specific dashboard from which you can access other services.

One of the benefits of SAML is that it provides a great user experience. Only a single credential is needed to log into different applications.

Security is another critical benefit of using SAML. It provides a single point of authentication, and the user's information doesn't leave the firewall boundary. All the different applications don't need to synchronize information between them, making the authentication system securer.

In addition, SAML is widely accepted by enterprises. It has been on the market for a long time and has gained the trust of enterprises.

One of the disadvantages of SAML is that it can be vulnerable to XML and DNS spoofing attacks, which makes the system less secure.

It's not suitable for personal applications like social platforms since setting up SAML is difficult; however, it works well for enterprise applications because employees won't need to think of multiple software that the company uses. Using a single set of login credentials, your employees can access all your software.

In addition, implementing SAML is a critical job. Different security aspects need to be considered, which might not be an easy job for a small-sized team.

Passwordless authentication is gaining more attraction because it's an excellent solution for providing a better user experience and increased security to your users. In this article, you learned about different popular passwordless systems and their benefits and disadvantages.

Passwordless authentication can be an excellent solution for your application, but it's crucial that you understand the use case and implement a solution suitable to your needs. Try Clerk free today to add passwordless authentication to your application within minutes – not weeks.