Passwordless connections allow users to log in without the need to remember a password. Instead, users enter their mobile phone number or email address and receive a one-time code or link, which they can then use to log in.
When a user authenticates via passwordless, the user is attached to the connection using Auth0 as the Identity Provider (IdP). Since you can't force users to use the same mobile phone number or email address every time they authenticate, users may end up with multiple user profiles in the Auth0 datastore; you can link multiple user profiles through account linking.
Passwordless connection vs passwordless login
A passwordless connection is another type of connection separate from any existing database, social, or enterprise connections. Even though a user from an Auth0 user database or social provider might share the same email address, the identity associated with their passwordless connection is distinct. As with linking multiple email addresses or mobile phone numbers used for the Passwordless connection, account linking can also be used to associate a passwordless identity with identities from other types of connections.
In addition to supporting passwordless with passwordless connections, Auth0 lets you define a passwordless flow using WebAuthn with Device Biometrics. To learn more, review Configure WebAuthn with Device Biometrics for Passwordless Authentication.
The benefits of using passwordless authentication include:
Improved user experience, particularly on mobile applications, because users only need an email address or mobile phone number to sign up.
Enhanced security: Passwords are a major vulnerability as users reuse passwords and are able to share them with others. Passwords are the biggest attack vector and are responsible for a significant percentage of breaches. They also lead to attacks such as credentials stuffing, corporate account takeover, and brute force attacks.
Reduces the total cost of ownership, as managing passwords is expensive (implementing password complexity policies, password expiration, password reset processes, password hashing and storing, breached password detection).
Supported authentication methods
Auth0 passwordless connections support one-time-use codes sent via SMS or email, and magic links sent via email.
When using passwordless authentication with SMS, users:
Provide a mobile phone number instead of a username/password combination.
Receive a one-time-use code via SMS.
Enter the one-time-use code on the login screen to access the application.
When using passwordless authentication with email, users:
Provide an email address instead of a username/password combination.
Depending on how you have configured your passwordless connection, receive either a one-time-use code or magic link via email.
Enter the one-time-use code on the login screen (or click the magic link in the email) to access the application.
To implement passwordless, you'll need to make two key decisions:
Which authentication factor you want to use (SMS or Email with one-time-use code, Email with Magic Link)
If you are going to implement authentication using Embedded Login or Classic Universal Login
The main driver for picking the authentication factor is user experience, and that depends on your application and its target audience. If the application will run on mobile phones, it is highly likely that users will be able to receive SMS messages. If it's an internal web application that is used in an environment where users cannot have their mobile phones with them, email would be the only choice.
If you decide to use email, then you need to decide between a one-time-use code or a magic link. We recommend using a one-time-use code because the login flow is more predictable for end users. To learn more about authentication factors, read the following articles:
Auth0 supports two ways of implementing authentication via a connection: Embedded Login and Classic Universal Login.
The industry is aligned in that Classic Universal Login is the proper way to implement authentication in all apps, but in the case of Native Applications, sometimes customers prefer to implement Embedded Login for UX reasons.