We all know the common procedure for authenticating a user in our application. It’s the old school method of registering a user with his/her basic info, like- email, password etc. and then at the time of login, match the given email, password with the previously stored data. If matched then give him/her access, otherwise not.
But time has changed and a lot of other authentication methods have been introduced over time. To keep yourself valuable as a programmer/developer at this fast paced, ever changing software development world, you need to know about these new methods.
It’s an undeniable fact that ‘Authentication’ is of the utmost importance in any type of application or system to keep safe the user data and proper access to information. To determine which authentication method is better for you would require the knowledge about the authentication methods, their trade-offs, and mostly how they works.
Here I’ll try to introduce you with the most common and popular methods of authentication using these days. It won’t be a detail technical guide for these methods but just an attempt to make you familiar with them. Though the following topics are discussed having the ‘web’ in mind, but the concepts are not limited to only that. These concepts and methods can be proved useful in other domains too.
I’m gonna continue my article assuming that you already know the fact that most of the web/internet — as we know it — is built upon the HTTP protocol. Also before proceeding, you should already know how a web application works, what does it mean by authenticating a user to the application and what is client-server architecture.
Ready for the journey? Let’s dive.
Since the HTTP protocol is stateless, this means that if we authenticate a user with a username and password, then on the next request, our application won’t know this is the same person from the previous request. We would have to authenticate again. At each request, HTTP doesn’t know anything about what happened before, it just carries the request. So for any request for private data, you would have to log in again to make sure the application knows this is really you. This would be very annoying.
To avoid this problem, session/cookie based authentication was introduced. It makes the authentication process ‘stateful’, This means that an authentication record or session must be kept both server and client-side. The server needs to keep track of active sessions in a database or memory, while on the front-end a cookie is created that holds a session identifier, thus the name cookie based authentication. This one is the most common and widely known method of authentication which is being used for a long time.
Basic flow of session based authentication:
A few major problems arose with this method of authentication.
Token-based authentication has gained prevalence over the last few years due to rise of single page applications, web APIs, and the Internet of Things (IoT). Token used for ‘Token based authentication’ is mostly Json Web Tokens(JWT). Though there are different implementations of tokens but the JWT have become the de-facto standard.
Token based authentication is stateless. We will not store any information about our user on the server or in a session, not even which JWTs have been issued to the clients.
Basic flow of token based authentication:
If you want a more detailed explanation, try here.
There are several benefits of this method:
Because of these benefits and simplified approach, Token based authentication is on the rise of popularity these days.
The first reaction to the term ‘Passwordless authentication’ could be — ‘how could someone be authenticated without a password? Is it even possible?’
That’s because we have had it drilled into our heads that passwords are the ultimate source of protection for our account. But after digging up some information about it, you might realize that not only is Passwordless authentication safe to use, it might even be safer than a traditional username + password login. You also might have heard people who raised their voice trying to establish that Passwords are obsolete.
What is Passwordless?
As you might have already guessed that, ‘Passwordless authentication’ is a way to configure login and authenticate users without a password. The general idea to implement a Passwordless authentication is following:
Instead of a user giving an email/username and password, they enter only their email address. Your application sends them a one-time-use link to that email, which the user clicks on to be automatically logged in to your website/application. In the case of a password-less login, the app assumes that you will get the login link from your inbox if the email provided is indeed yours.
There is a similar approach, which is instead of sending one-time-link to email, sending a code or one-time-password(OTP) through SMS. But you need to incorporate your application with a SMS service, like twilio, to make it work (also it will cost you money). Also, it’s good to know that code or One-time-passwords can be sent to email too.
If you are using Slack, you might already get a taste of Passwordless login.
Also Medium is giving user’s access to their site using only Email. I recently found that, Auth0 or Facebook’s AccountKit could be a very good option if you want to implement a Passwordless system in your application.
What could go wrong with Passwordless?
If someone has access to the user’s email account, they would have access to their account in your website/application too. Well, don’t worry about that. Securing the user’s email account is not our(as a developer) responsibility at all. Also, if someone gains access to one’s email account they can exploit their ‘password-based authenticated’ applications too using ‘reset-password’ feature. So, let’s move on as we have nothing to do about it.
What’s the benefit?
Before answering that I ask you to just think about how frequent you use ‘forgot password’ to reset your passwords, not mentioning the several failed attempt before that, to login a site/application just because you can’t remember the goddamn password? Well, that’s not only the case for you my friend. We all are in the same boat. It’s no wonder that remembering password is hard, specially if you are concerned with your account safety and set different password in every site (following the at least ‘a number’, ‘a capital letter’, ‘a symbol’, ‘minimum 8 character length’ rule). Using a Passwordless authentication will save you from this headache. (I know, now you might thinking, ‘I use password manager you idiot’. Respect to you. But remember, mass users of your application are not tech-savvy like you. You need to consider that.)
Not only for users, as a developer it is good for you too. Now you don’t need to implement a ‘forgot password’, ‘reset password’ flow. This is a win-win for all. Cheers!
If you really think that some of the users might still want to use that age old email-password login, then you should give both of the options like Slack did, so the users could opt-in.
Needless to say that Passwordless is becoming an increasingly relevant option for login and gaining popularity these days.
Did you notice that if you login to any of the google services like your gmail account from your browser, and then you go to youtube or any other google based service, you don’t need to separately login for that service? You automagically gain access to all of the google services. Fascinating, isn’t it? Though gmail and youtube are both products of google, but they are separate products, right? So, how do they authenticate a user after single login to all of their products?
This method is known as Single Sign On (SSO).
Single sign on can be achieved in many ways. One of them is to makes use of a Central Service which orchestrates the single sign on between multiple clients. In the example of Google, this central service is Google Accounts. When a user first logs in, Google Accounts creates a cookie, which persists with the user as they navigate to other Google-owned services. The process flow is as follows:
Single Sign On (SSO) can be described very simply as “user logs in once and gains access to all systems without being prompted to log in again at each of them”. This boils down to three different entities who trust each other directly and indirectly. A user enters a password (or some other authentication method) to their identity provider (IDP) in order to gain access to a service provider (SP). User trusts IdP, SP trusts IDP so SP can in-turn trust user.
This seems so simple, but custom implementations of this would be very complicated. A details explanation on how SSO works can be found here.
I bet the following image is pretty familiar as you frequently see it in most of the sites, right?
This is the thing which is famously known as ‘Social sign-in’ or ‘Social Login’. Using this you can authenticate a user based on their social networking accounts. Users don’t need to register separately in your application.
Social sign-in or Social login is not technically a different authentication method. Rather it’s a form of single-sign-on which simplifies the registration/login process of a user to your application and that’s why you should know about it (as a developer).
Social login is best of the both worlds. Why?
First of all, for the users, the login to your application is just one click away as they can use their existing social network account and don’t need to remember username, password for services like your application. This results in a rich user experience. Also as a developer you don’t need to worry about securing user’s authentication credentials and also you are ensured that user’s email address is already verified (by the social service providers). Another bonus point, social provider will also handle the password recovery process. Yay!
How do I do it then, huh?
As a developer you need to know a little bit more about the underlying process. Most of the social providers use OAuth2 (some uses OAuth1, e.g. twitter) for authorization as well as authentication mechanism behind the scene. The major key points to understand in OAuth is that, the social provider is the ‘resource server’, your application is the ‘client’ and the user trying to login to your application is the ‘resource owner’, because the key ‘resource’ here is the user’s profile/authentication information. So, when the user wants to login to your application using the social provider your application will redirect them to the social provider for authentication (generally a popup window opens with the social providers URL). Along with the successful authentication, the user needs to approve your application’s permission to access the user’s profile information from social provider. Then the social provider will redirect back the user to your application with some access token. Next time using that access token your application can ask the social provider about the user’s profile information. This is how OAuth works in a nutshell (skipping some technical details for easy clarification)
To implement social login in your application you might need to register your application in the social providers site which will give you some app_id and other related keys for configuration to communicate them. You will get these information in the respective social provider’s site. Also there are several popular library/packages (like Passport, Laravel Socialite etc.) which might simplifies the process for you and release you from the burden to know the nitty gritty details.
Two-factor authentication (2FA) strengthens access security by requiring two methods (also referred to as factors) to verify a user’s identity. It is a type of multi-factor authentication which provides an extra layer of security. You might not realized before but when you go to an ATM booth or Cash machine to withdraw money, you are being authenticated by a Two-factor authentication system. You must have the correct combination of the bank card(something you possesses) and the PIN(something you know) to be authenticated. If someone steals your ATM card, it is of not much use until they also know your PIN. That means in a Two-factor authentication system a user is granted access only after successfully presenting several separate pieces of evidence to an authentication mechanism.
Another example you might be familiar with is the 2-step verification of Google, facebook etc. Where after enabling 2 factor authentication in your account, every time you need to login to your account, first you provide the login credentials, such as email, password(verify that you know the credentials) and then a one-time password(OTP) is sent to you through SMS(verify that you possesses the device), and you have to enter it correctly to complete your login process. If your password has been compromised, your account is still safe, as the attacker cannot complete the second step without having the verification code.
Instead of OTP, another common method is to use the user’s biometric data such as fingerprints or retina as a second factor.
Two factor authentication is based on the user providing two of the following three “somethings”:
Learning the password or pin for an account is what most hackers go after. Accessing a physical token generator or getting biological features is harder and the reason why 2FA is effective in providing greater security for user accounts.
But, still it will help you to strengthen the authentication security in your application. How would you implement a 2FA solution in your system? Well, it might be better to use some existing solution like Auth0 or Duo rather than rolling your own.
Some of us might mistakenly use the terms ‘authentication’ and ‘authorization’ interchangeably. But these two terms doesn’t mean the same thing.
Are you still here?
Congratulations, you’ve successfully completed reading a long, tedious, boring article. 😃
Hope you get a brief overview about the topics. If you find any mistakes or think any improvements needed in this article please leave a comment.