Authentication: Part-1
This is my first blog in a series of blogs about Authentication. I will just be putting out what I have learnt about them. This blog is about the Login and Signup forms.
Authentication is the most common thing you will come across in your daily and developer life. And the most common thing you can come across all of them is a form. Most probably a Login or Signup form.
While technically, both the login and signup forms are different in what they perform, modern forms have found ways to merge both of their functionalities into a single one.
The backend is just a means of communication with your database.
Signup Form:
Traditionally, a signup form is where you take the user information and store it in your database. No sort of token or session is issued here.
While storing the user data in your database, we should not store the user credentials directly in the DB. It is expected from the developer, that you use some encryption while storing this sensitive info in the DB. This encryption/hashing is done mostly using the “bcrypt” library.
Here’s a rough outlook of how a signup flow looks like:
Putting the flow into words, when the user at the browser or simply the client submits the signup form, a request will be sent to the backend/server containing the submitted information.
Then, after ensuring the data is new to the DB, the server performs an operation where it stores this data to the DB. The DB, after storing the data successfully, sends back a response with a status code of 200, representing a successful operation. The same response is sent back to the browser.
At the browser, we usually have some code that acknowledges the response and sends a notification to the user saying you can log in now or just redirecting the user to the login page.
Login Form:
A Login form is where you ensure that the user has signed up and send back a response to let the user in.
The Login flow looks something like this:
Translating the flow into words will look something like this:
When the form is submitted at the browser, a request is sent to the server along with the submitted data.
Get Sai Baba’s stories in your inbox
Join Medium for free to get updates from this writer.
At the server, we should ensure that the user data is already present in our DB. Coz, if it’s not there, we should make sure that the user signs up first.
After ensuring that the user has signed up, we should issue a token or a create a sessionID for the user and send it back along with the response. It doesn’t end here. If we go a little bit more deep into the internals —
At the browser, we have to store the response at somewhere like local storage or session storage or cookies (choosing one of these is a different topic altogether). And, just write a condition check that acknowledges the data in those storages and lets the users enter your application.
There are some things missing here. I will write a dedicated blog on internals of this mechanism.
Some other practices:
While these two are the traditional ways of authenticating users, modern websites have been using just a single form with has functionalities of both the Login and Signup forms.
It does make sense when you think about it. Because, all a sign-up form does is, writing the users into the DB. You can just do these things at the same time. The flow must go something like this- check the user info in DB, if the user is not present- create, if the user is present, generate a token and send back the response.
When building a new site, it doesn’t necessarily mean, you have only this way of Authentication. There are number of other ways to let users in.
You can let users login through their Google Accounts using Google’s OAuth.
Other popular ways include using emails or phone numbers to send an OTP, or using a magic link to verify the user’s email and a number of other ways.
Here’s a little other topic I thought I could cover:
Authentication vs Authorization:
Authentication is the whole process of sending the user info to your backend\server, doing some jargon at the backend & sending back the data to the client. This whole process is termed as Authentication.
Authentication is just saying to users, “Yeah man, I know you. You can go and access my site”.
Authorization is checking the data the user just entered and the data in your DB are the same or not. If both match, you send back a response that allows the user to enter your application. Authorization is a part of Authentication.
Authorization can be roughly translated into “Do I know you? ( Waits & looks up in the DB & confirms), Yeah, man I know you.”
What’s up next:
Will dive into some traditional methods like JWTs and sessions in the next blog.
Thank You.
