The topic of our discussion: Access token and Refresh Token.

Let me explain it in simple language:

Imagine you have a secret club, and you want only members to enter. To control access, you give each member a special badge (like an access token). Now, when someone wants to enter the club, they need to show their badge at the door.

In the digital world, websites and apps use access tokens for a similar purpose. When you log in to a website or an app, they give you a special access token. This token is like your digital badge. Whenever you want to do something on the site, like view your profile or post a comment, you have to show your token.

Access tokens help in two main ways:

1. Security: Just like only members can enter the club with their badges, only users with valid access tokens can perform certain actions on a website or app. This keeps unauthorized people out.

2. Convenience: Instead of entering your username and password every time you want to do something on a site, the access token acts as a quick pass. Once you log in and get your token, you can use it for various activities without constantly re-entering your login details.

So, access tokens are like digital keys that allow you to access specific parts of a website or app securely and conveniently.

The Access token is short-lived, let's say for a day.

What happens after a day?

After the access token expires, the user needs to refresh it again.

Google has proposed in its research paper that we should use two tokens instead of a single token. It makes the authentication process more secure and convenient.

One is the "Access token" which will not be saved anywhere permanently; the user has access to it only. It will be short-lived, for example, 15 minutes or 1 hour, so that the user can do constant work without interruptions.

One more token is known as "Session storage" or "Refresh token" .This tokens have a longer lifespan compared to access tokens. They are typically valid for days, weeks, or even months. This will be stored in the server database.

Suppose the user's Access token has been invalidated or expired. Instead of telling the user to log in again to get Access token, the server can send user a 401 error that means the request has not been applied because it lacks valid authentication credentials for the target resource. A server generated 401 (This status code is not fixed; it is in the hands of the backend developer to choose the status code in response to the situation) response will be sent to the user.

The frontend user can then write code to handle this issue by hitting the Api endpoint. If he gets a 401 error response , and get a new updated Access and Refresh tokens.

How does the user get a new token ?

When the user makes a request by hitting the Api endpoint, the user sends the refresh token along with the request object to the server. As soon as the server receives the refresh token, it matches it with the one stored in the server database. If they match, new Access and Refresh tokens are generated and sent back to the client through the response in cookies.

Thanks to Hitesh Choudhary Sir, I learned all this stuffs from his YouTube channel: