Mehul Kundu
Mehul Kundu

Mehul Kundu

UX Case study: Comparative analysis of authentication flows

UX Case study: Comparative analysis of authentication flows

How the modern user registration and authentication works in Web2

Mehul Kundu
·May 14, 2022·

7 min read

Subscribe to my newsletter and never miss my upcoming articles

Table of contents

I'm creating this blog in Notion (which is my go-to solution for all of my notes, blogs, program planning, and, in general, everything that needs to be in written format) before publishing it on Hashnode. Similarly, we utilize a significant number of SaaS or online services on a daily basis that require us to log in. And because I make a video about design, development, and productivity every day to put on YouTube, I usually come across a lot of products with various types of authentication built in. As a result, my UX designer self feels excited about exploring and publishing this topic.

In this case study, I'll solely talk about the authentication flow and user pain points regarding it. Taking data inputs, categorizing inputs, and recommended practices for creating a complete sign up page are not covered here. The key purpose is to choose the workflow.

In general, any authentication process for any online entity has two phases.

  1. Sign Up/Register: Registering an user for the first time in the platform.
  2. Login/Sign Up: Authenticating an existing user to give them access.

While registering a user, the information that we have to collect is:

  • Username or email address or phone as a unique identifier
  • Medium of communication usually email id or phone number
  • Verification type (We will look at different types of verification processes here)
  • User data (optional; will have an elaborate discussion regarding it in other case studies)

And for signing in, we simply need to allow the user to log in using the same workflow that they used to register. (Consistency + Jakob's Law)

Sign-up processes (classified based on the process of verification):

Here are some commonly used sign-up or login processes for user-generated sign-ups.

1. Email address (or username) + password:

Email serves both as a communication medium and a unique identifier. But at the time of signing up, we can set a username (if the option is provided), which later on can be used as a unique identifier as well. A password is required as a verification step.

image.png image.png

One of the classic examples of it is the GitHub sign-in process. And recently, they have introduced an awesome registration flow that is certainly worth a dedicated case study.

image.png

A one-time link to log into the site will be delivered by email, which is required as a communication method as well as unique identifier.

Now, two things can happen if you click on the link that you get in the mail -

image.png

  • You will be logged into the signup window you already opened - In this situation, the end result will appear in the user's current window regardless of which device they use to check in to their email account and confirm the one time link. For example, a person may have their email client on their phone yet use the platform on their computer. They can quickly log in to the platform without leaving the desktop screen, and they don't need to log in to the mail client to complete the flow if the desktop is an untrusted device.
  • The link will open a new window in which you will be logged in - Continuing with the previous example, if a person receives mail on their phone, the phone goes to their mobile browser and signs them into their account. Even though they are using their desktop as their current window, the user is inconvenienced.

But all in all, it reduces the hindrance of user auth to a great extent but is not ideal for the cases where multiple user-related data is required to get started with (like name, government id, phone number, SSN etc.).

image.png

One of the best login service providers in this category is Magic.link. It follows the first case scenario that I just explained about magic links. They've also lately added email-based Web3 authentication, which is one of its kind. As they are providing a complete solution for auth, they have other services like social auth, bio-metric auth, and other services which we will discuss later in this study.

image.png

image.png

3. Phone + OTP:

A phone number is required as a method of communication for receiving a one-time password to authenticate in to the site. And this serves as a single source of truth for the user. In case user loose the number or can't access to the phone right at that moment, it will be a disaster.

image.png

image.png

We can see this kind of authentication process in most websites where phone numbers serve as the primary requirement of user data. I have an example here from the Cowinwebsite, which is the COVID vaccination registration portal of the Indian govt.

image.png

4. Social/Third party login provider:

This solution relies on a third-party authentication provider such as Google, Github, Twitter, Apple, Microsoft, Auth0, and others to handle the credentials.

image.png

image.png

A great example of this kind can be found in Hashnode, where they have provided multiple numbers of social auths.

image.png

5. Bio-metric login:

This is the most recent type of authentication system that truly alters the authentication process. It required email as a method of contact and a unique identifier upon signing up. It also uses the device's built-in biometric authentication mechanism to verify, and if it can't find anything, it just sends a magic link to the mail account.

image.png

image.png

Passage.id has recently become the leading authentication provider in this category. You can actually experience how this workflow works here - [Click me] with a dummy registration made by them.

image.png

Comparison and Drawbacks

ParametersEmail + PasswordEmail + Magic LinkPhone + OTPSocial/Third partyBio-metric
Security StrengthIt is up to the user to create a secure password.Only secure if the mail client is on the user's trusted device.It is only secure if the device with a phone number is the user's trusted device.Only if the device logged-in is trusted by the user.Only secure if the mail client is on the user's trusted device.
Security ensured byDeveloperDeveloper / ProviderProviderProviderProvider
Password manager friendlyYesPartiallyPartiallyNoPartially
Secure login into untrusted deviceYesYesYesNoPartially
CostLowLow if self developed Medium if using providerHighIn most cases freeMedium
DrawbackUsers who do not utilize a password manager must remember their login credentials. Many people fail to create a secure password. Or, even worse, use the same password across all platforms.If the magic link does not support logging in, the current window creates inconvenience. It is always necessary to have access to a mail client.Access to phone is always necessary.It is necessary to log in to a social/third-party provider. It is inconvenient if the user is using an untrusted device.When a user is using an untrusted device, biometric authentication is not possible. Users must use a mail client if you are not utilizing biometric authentication.

Solutions:

Passworded + Passwordless: (That I have observed till now)

This is the most frequently utilized procedure across all platforms. Suppose we have email + password combination as well as social login. The following is an example from Wix that shows how both signup processes are present. Password and social signup options are available to users.

image.png

However, given both of their flaws, we need an extra step to convince the user in any case after initial registration to close the loophole. Coursera has an option like this in their settings section, where you may choose other sorts of authentication processes if you have an email + password login procedure or one social authentication provider attached to your account. This completes the loop.

image.png

image.png

All in all a combination of password and any other verification method can create a fool proof authentication flow, considering that both password and password less system is connected internally. Basically both the credentials are saved in one tuple of the database.

image.png

Thanks for reading this blog. Please share your feedbacks.

Did you find this article valuable?

Support Mehul Kundu by becoming a sponsor. Any amount is appreciated!

See recent sponsors Learn more about Hashnode Sponsors
 
Share this