How Authentication Works: A Step-by-Step Explanation of the Process Behind Signing Up and Logging In

How Authentication Works: A Step-by-Step Explanation of the Process Behind Signing Up and Logging In

I recently wanted to build a project where I was required to have a feature to authenticate users. I was presented with multiple options; I could use Google Sign In, for example, and some libraries to get this thing done. But that wouldn't quench my thirst for understanding what is happening behind the hood.

So, I decided to implement a login flow myself. I asked myself, how do I implement this? How do I verify that the user who is connecting to the server is a valid user?

We can have a simple sign-up flow to define who is valid or not. We'll start with the case where the user is not registered but wants to access our server features; one feature could be to get cute dog videos. I love dogs.

Here is what we want from the user:

  1. We take the email and password of the user using some form.

  2. We then save it to a DB, and once saved, we return a greeting that you have successfully signed in.

But the next time they send us the request to get the dog videos, we'll be confused if this request came from them.

For simplicity, let the email be and a super strong password that even quantum computers cannot break: 123.

For a moment, assume you are a server; you serve dog videos to whoever can prove that they have already registered with you.

Let's say Alex sent you a request:

GET /videos/dogs

As a server, all you would see is a simple GET Request: It doesn't have any identity attached to it. Bob can also send the same request:

GET /videos/dogs

But Bob is not registered. As a server, you have to send the videos to Alex but not Bob. Even though Alex has registered himself, his and Bob's requests are identical. What can we do?

Why not pass the credentials along with the request?

Hmm, I hear you, but how? In headers?

That could be one solution, but do you know anybody can intercept your request, and once they do, they can get hold of your credentials? And who knows how many places you have used that same quantum-safe password?

Why not encrypt the credentials, then?

Are you saying you'll encrypt the credentials from your side? And how will the server know how to decrypt it?

Well, I can send the key to decrypt in headers. But if we do that, we are again back to square one; anybody can intercept and decrypt the key.

Come on, think, think!

Why does the client need to do any of the above things? That'll be super complex, and nobody will like watching the dog videos from your website.

Since we are engineers, we have to think of a way.

Let me think out loud: When the user signs up the first time, the server will generate an encrypted token using our credentials (that, as a client, we need not be aware of). The server will then save that token in our Cookie.

Cookies are small pieces of text sent to your browser by a website you visit. They help that website remember information about your visit, which can both make it easier to visit the site again and make the site more useful to you.

The thing with cookies is they will be sent automatically to the server whenever you make a GET request for a dog video on the website.

This time, when you sent a request to watch a dog video, the server received two things:

  1. GET /videos/dogs

  2. Cookies (associated with your website).

Now, the server takes the Cookie and eats it, and when it is done eating it, it sends you the videos.

Just kidding, since it was the server that encrypted it, it knows the key to decrypt it as well; it decrypts it and gets the information: {emai:, password: 123}. It then matches it with the DB, and once it verifies that, it happily sends you the videos.

Everyone is happy; you got your dog video, and the server got his cookies.

But how do I implement it? This I will elaborate on in my next post.

PS: This is an overly simplified article on how the login flow works. I have deliberately left a few things, such as:

Thank you for reading this article. If you like this article, please show your support by subscribing to my newsletter or commenting.

Did you find this article valuable?

Support Kishan Kumar by becoming a sponsor. Any amount is appreciated!