🔑 Introduction
Almost every application requires some kind of authentication for giving users the security they need. But implementing authentication in your applications can sometimes become a daunting task especially if you do not approach it the right way.
You may have used any library such as Passport.js, Auth0, Grant, etc. to achieve this task but didn't quite understand how does it actually works, what goes behind the scene, etc. And it is totally okay if you are just exploring something or making an MVP(Minimum Viable Prototype), etc.
But with time, as you grow as a developer these abstractions start to nudge you. And even though you use these abstractions but you feel the urge to understand the alchemy behind the magic these libraries do.
In this article, I will try to take you through the process of understanding the basics of what authentication is and how to approach it the right way. But do not expect becoming an Auth Ninja 👤 after reading this article, this is just the basics of how and why authentication libraries work the way they do. But you can always take it further and solidify your understanding.
🔐 What is authentication?
For starting the journey forward first, you need to understand the meaning of Authentication - specifically in the app world. In very simple terms Authentication refers to the process of verifying the users. It is used to prove that the users really are who they say they are.
It helps to safeguard your application and provide users with the promise that their data will only be accessed by them. No one, that does not have the right to it can access the resources.
😐 A simple authentication approach
The most basic form of authentication can be credential-based authentication. A user is asked to provide a secret string of characters(password) along with a unique identifier(username) that only they know for authentication. This auth data is attached to their data on the server. Now, whenever the user wants to access the resources, they are asked to put in the username & password to verify their authority over the resource.
This method is as simple as it sounds but is still used as the basis of all the modern authentication techniques. Adding subsequent layers of extra security make the process more smooth & secure both for users and the application developers.
😒 Why is this just not enough?
As the life of people getting more and more dependent on computer applications, the apps are becoming much more complex. Hence they require better security and trust than ever before. And the simple approach alone does not solve the problem in a very elegant way.
For example, let's take any web application that is connected to a server that provides an API to access the data. This is the typical form of applications being developed nowadays. Now the server is a stateless entity that starts with a request and ends with a response back to the application. It does not keep track of any of the previous requests made.
So whenever a user performs an operation that requires data, the application has to ask the user for the credentials. It then passes them to the API in order to get the requested resource.
Now for a very simple application, this might be all the data that is required, and feels absolutely no problem in asking for the credentials from the user for this one-time action.
But applications nowadays are much more complex and are required to talk to the server multiple times in a single instance. And asking for credentials every time from the user is not at all good UX.
Moreover, the user cannot remember different username-password combinations for different applications hence they use the same set of credentials over multiple apps. This in turn puts all of their online data at a huge risk. A data breach anywhere jeopardizes their data everywhere.
📟 Token-based authentication
Solving the problem of authentication is not that straightforward as more of them keep emerging every day. But, the token-based authentication approach tries to solve most of them and is, therefore, the most widely used technique as of now. Almost every other application uses one or a similar form of token-based authentication. So what does a token-based authentication look like?
In layman terms, a token is just a unique string of random alphanumeric characters that are encoded using some secret. The application sends this token with every request and if valid get access to the data requested.
⚙ How does it work?
- When a user logs into their account by entering their credentials, a unique token is generated at the server using a secret known as "salt". This salt is only known to the server.
- This token is then returned to the application and the application stores it inside the browser for future use.
- The application then sends this token along with every request to the server.
- The server then verifies the authenticity and validity of the token using the salt.
- If the token is valid, the server sends the requested data to the application.
- This cycle repeats for every request.
✔️ How does it solve the problem?
- The token is automatically sent along with every request so the user does not have to enter the credentials every time.
- The token comes with a time limit called TTL(Time To Live) which generally expires within a day, this prevents password theft as the token becomes invalid after the TTL.
- The token may also contain some useful data in the form of payload. This saves the need for querying the database for this information and saves time.
- The token is valid for just one application. If the token is compromised it does not affect any other application (which was the problem when using the same password over multiple applications).
There are many ways of using a token-based authentication approach and it really depends upon the specific needs of the application. Some require more boilerplate, some require less. Implementing a full-fledged authentication system that is free from any drawbacks is almost impossible. That said, one can always make it more secure by following best practices, keeping an eye on the user behavior on the app, etc.
🏁 Conclusion
Nowadays implementing an authentication system has become more and more complex trying to cover every edge case to make it more robust. And the simple ones are just not safe enough to be used on privacy-centric applications. This is a common problem for almost every application out there. Every app requires some level of authentication and since it is such a sensitive part of the app, people often suggest using a cloud provider for auth.
Here are the only reasonable options for authentication in apps:
1. Use a cloud provider for auth
2. Have a team dedicated to auth for the company's apps
3. Use HTTP basic auth because security clearly doesn't matter that much for you anyway 🤷♂️17:19 PM - 29 Aug 2020
I hope you got the gist of what authentication means and the science behind it. As said earlier you should try to use a cloud auth provider for production applications as and when possible. But there's no stopping you from trying it on your own. And it always helps in a deep understanding of something when you try to implement it. The more you explore it the more you know the deeper aspects of it.
There is also an article coming soon where I will try to implement 2-3 flavors of Token-Based authentication systems. Meanwhile, you can try on your own. Here are some resources that might interest you.
Also, feel free to follow this space for more such articles & ya don't forget to give this a heart ♥ if you like this.
Happy Coding. Cheers 🍻🎉
Top comments (0)