Full-stack development is not just about making the front end talk to the back end, and vice-versa. You need to keep additional peripherals in mind to put yourself in the shoes of a full-stack developer.

A full-stack developer should be equipped with the knowledge of various aspects of system design and authentication & authorization is indeed one of them. In this article, we will learn the concept of authentication and authorization fundamentally.

If you like to watch the content as a video, this tutorial is also available as a visual video explanation on my YouTube channel. Please take a look. 😊

What is Authentication?

Have you been to an ATM kiosk to withdraw money? I'm sure you did. So, if you have gone to an ATM kiosk how do you withdraw money from your account? You have to insert your card first into the card slot, then give a secret pin to let the ATM know that this account belongs to you and you are then allowed to withdraw money from it.

The ATM has software to verify your card and PIN details to determine whether the person providing the PIN is the right person supposed to do that, and if the match happens it will allow you to withdraw the money.

So, this pin is a specific secret that is given to you and it should be only known to you or a hacker or a person with whom you have shared it. But ideally, it should be only known to you.

This secret pin is also called a credential. The credential is something that you provide to let a service know who you are and whether you are the legitimate person to act on that service. This particular mechanism or letting a service know through a credential is called authentication.

The authentication mechanism can be classified into two types, single-factor authentication and multi-factor authentication.

Single-factor Authentication

in the case of ATMs, you authenticate to ATM services using a secret PIN or credential. Similarly, when you want to access something confidential from a database or a server, you have to let the server or the database know who you are. Are you the person who should be granted access or not? For that usually, you provide a combination of a user ID and password.

The user ID and password get matched at the backend server and then if your identity is found, you will be granted access to do something otherwise not. This way of authenticating with the user ID and password is known as single-factor authentication.

This is one of the oldest methodologies of authentication and usually, it is not that secure. Because we as humans have different patterns of managing passwords. We usually don't change our password very often, for many services we tend to repeat the same password, so it means for a hacker if they identify one password for one service(let's say for Gmail), it will be extremely easy for them to use the same for any other services and gain access on behalf of you.

So you need something additional, some other factor that ensures you are better connected to confirm yourself as a legitimate user.

Multi-factor Authentication

The single-factor authentication is not that strong and that's why we are going to talk about another methodology of authentication which is called multi-factor authentication. The multi-factor authentication could be of any factor. For example, it could be two factors, three factors, and even more.

What does factor mean here? The factor means the different types of authentication mechanisms chaining together to authenticate the user to the system. we already know about credential-based authentication, but nowadays for many online platforms, there is a famous mechanism called OTP(one-time password) chained along with the regular credentials to authenticate users.

Even after authenticating using your user ID and password, the system sends a one-time password on your mobile devices through SMS or email, which you have to feed into the application to tell and verify who you are. Nowadays you also use the authenticator apps to get one-time passwords from many applications.

Sometimes this two-factor authentication also may not be enough and we want more factors included. For example, you can do biometrics, like thumb impressions, retina scans, etc.

This kind of multi-factor authentication is extremely hard for hackers to break through. The more factors you put into authenticating your users, you make your system that secure. However, it is not always feasible for every application to do it because certain things will be costly for you to implement.

You have to decide to what extent the implementation is needed for your application. Sometimes it might be just a user ID password, sometimes it could be a user ID password and an OTP, and at times you could be going to the next stage of doing biometrics.

How does the Authentication work?

Let us understand the authetication flow with this simple and quick story.

Meet Sam, who would like to access a service from a server, and behind the server, there is a database.

• Now Sam is talking to the server saying, "Hey server! Get me that thing now...".

• The server wonders who is this guy asking me about 'that thing'! Let me check my database whether the guy exists or not.

• So the server goes back and checks into the database asking, "Hey database, can you check whether this guy exists there?".

• The database checks and comes back saying that no I didn't find this guy, so buddy, I can not give him "that thing".

• Now, the server goes back to Sam, and asks, "Bro! Who are you? I don't know you.". That means the server is asking Sam to authenticate using Sam's credentials and/or with any other factors so that the server can verify Sam is Sam.

• Then, Sam uses his credentials to authenticate and the server grabs the details to ask back the database again about Sam's existence.

• This time database can recognize Sam with his credentials and informs the server about that.

• Next, the server creates something called token and gives that to Sam to use in his subsequent requests to the server. With the token, Sam doesn't have to provide the credentials every time. He can use the token like a secret key to ask anything else from the server. The server will validate the expiry and authenticity of the token before serving Sam's request.

• Now, Sam requests again "Hey server! Get me that thing now...", but this time, he also passes the token along with the request.

• The server validates the token and agrees to respond to Sam with that thing, 🥚.

I hope the authentication flow is clear to you now. Let us now move on to understand authorization.

What is Authorization?

While authentication is the way to tell someone who you are, authorization is the way to provide someone access to resources they are supposed to have.

Have you been to a shopping mall or a grocery store? I am sure you did. When you visit there, you are allowed to pick up the items, put them into your cart, push them to the billing counter, pay, and checkout.

However, you are not allowed to enter the areas that are "STAFF ONLY"(unless you are also a staff in the same shopping mall). You need to have a proper authorization to enter that area. Your role in that shopping mall decide if you should be authorized to access a generally prohibited area and service.

I hope this analogy works to a good extent with authorization. Now, let us go back to Sam's story once again and understand the authorization flow better.

How does Authorization work?

Consider Sam is already authenticated and he is asking for the payroll details of a few employees reporting to him.

• Sam sends the request to fetch payroll along with the token to the server.

• The server gets the request, validates the token, confirms Sam's existence, and then looks up the access Sam has to the resources.

• The server finds that Sam has an engineering manager role with permission to view the payroll details of all the employees reporting to him.

• The server fetches the payroll details from the database and sends it to Sam as a response.

That was a happy scenario. Let us also consider another scenario when Sam requests the server for the same payroll details but this time of his manager!

• The server validates the token again and finds out the access details of Sam.

• However, this time the server finds that Sam is not supposed to access his manager's payroll details, as, he is not authorized to it.

• The server responds with an error message and error code that Sam doesn't have access to the requested resource.

That's all. I hope this article gave you a basic, yet solid understanding of authentication and authorization. Now, you can start exploring more advanced topics around it. I would recommend you to learn about these concepts next:

• Cookies

• JWT Tokens

• OAuth

• RBAC

If you liked this article, please LIKE/SHARE/COMMENT so that it reaches others as well. Thank you for reading.

---

Let's connect. I share knowledge on web development, content creation, Open Source, and careers on these platforms.

• tapaScript on YouTube

• X(Twitter)

• LinkedIn

• GitHub