HTTP is a stateless protocol and each request is independent. This means that a request does not hold or store information about any previous HTTP requests. Then the question arises, how do we authorize a user? If HTTP is stateless, then perhaps, we need to authorize and authenticate a user every time they make a request to our server. This is inefficient and costly to authenticate a user every time they make a request. So, there exist solutions that help us solve this problem. These are:

1. Session-based authentication
2. Token-based authentication

Session Based Authentication#

In session-based authentication, we take the user’s email and password, validate them, and then store a session for the user in the database. The session is sent back to the user in the form of a cookie. Now, whenever the frontend makes any requests to the backend, this cookie is part of it. This cookie is validated every time a request is made. If it’s valid, the user is able to perform the desired actions.

Some Problems Linked with Session Based Authentication#

1. A problem that can arise from session-based authentication is Cross-Site Request Forgery (CSRF). A hacker can perform actions on your behalf. For example, they can trick you into changing your password, or if it’s a banking app, they can craft a phishing link which sends money to their account. The main gateway for CSRF to happen is that the user is logged in via cookies.

2. In a distributed environment, it’s hard to maintain sessions. Say you have multiple servers and replicas of your DB. In a distributed system, it is not guaranteed that a request from a given user will always go to the same server. It’s quite possible that one request is handled by one server and the next request by another.

3. Storing and retrieving session information from the database or memory is a costly process. Each time a new user authenticates, we need to store their information. And whenever a user sends a session ID with their request, we need to validate it from the database or memory. This leads to a lot of back and forth, especially in a distributed environment.

Token Based Authentication#

Next, we have token-based authentication. When a user logs in via email and password, instead of creating a session, a signed token is created and sent back to the user. The client-side saves that token in the local storage and uses it for subsequent requests to the server. Whenever the token is sent to the backend, it is decoded, verified, and then the response is sent to the client. Also, when the client logs out, the token is destroyed.

Better than Sessions?#

This is better compared to sessions because there is no overhead of maintaining sessions in the database. When the request comes to the backend, the token is verified. Hence, this can work and scale well in distributed systems as well. They are not vulnerable to CSRF attacks.

Types of Tokens#

There are basically two types of tokens:

• Access Tokens: Are created when the user logs in for the first time and are used whenever the user requests some resource.
• Refresh Tokens: Are used to gain new access tokens in case the previously used access token has expired.