JWT Based Authentication
When we deal with backend authentication, the first thing that comes to our mind is JWT authentication.
So in this article, we will deep dive into JWT-based authentication.
We will understand:
What is JWT?
What is the structure of JWT?
How we authorize users using JWT tokens
What are Access Tokens and Refresh Tokens
What is Authentication
What is Authentication?
When a user logs in, the backend verifies the provided credentials (such as email or username and password) and then backend gives access of system to the user.
This process is called authentication.
Authentication is of two types:
Stateful Authentication
Stateless Authentication
Here, we will understand how the stateless approach takes place.
What is JWT (JSON Web Token)?
JWTs are used to securely transmit information between different parties (for example, client and server).
It is just a string like this:
Structure of JWT
JWT is divided into three parts(three parts are divided by dot)
Header
Payload
Signature
1) Header
It consists of two parts:
Type of token (JWT)
Signing algorithm used to sign the token
It is encoded in Base64URL to form the first part of the token.
2) Payload
It contains data.
Usually, we don’t store confidential data here because if the JWT gets stolen, anyone can read the payload.
It is also encoded in Base64URL to form the second part of the token.
3) Signature
Here:
We take the encoded header
We take the encoded payload
We add a secret key
Then we sign the token
This creates the signature — the third part of JWT.
Can Someone Steal JWT?
Yes, someone can steal a JWT and try to access protected routes.
So what we do is:
We add an expiry time to the token.
For example: 60 seconds (1 minute).
After that time, the token expires.
But if we keep the expiry time too short, it creates a bad user experience because users have to log in again and again.
Access Token & Refresh Token
So what we have seen till now:
The token which lasts for a short time is called an Access Token.
If we don’t want the user to log in again and again, we also create a Refresh Token, which is long-lived.
Access Token → Short-lived
Refresh Token → Long-lived
Flow
Here’s what happens:
User logs in
If the user is valid → Server sends Access Token + Refresh Token
Then:
With each subsequent request, the user sends the Access Token
If the token is valid → Server verifies it and gives access to data
If the Access Token expires → Server sends a 401 error
Frontend logic detects 401 and sends the Refresh Token
Server verifies the Refresh Token
If valid → Server sends a new Access Token
But What If Refresh Token Gets Stolen?
It can happen that someone steals the refresh token as well.
So for that We store the refresh token in the database and We add one more security layer called Token Rotation.
Token Rotation
Here’s what happens:
When the Access Token expires, the frontend sends the Refresh Token to create a new Access Token.
In Token Rotation, we also create a new Refresh Token each time along with the new Access Token.
So every time a refresh happens, a new refresh token is issued and the old one becomes useless.
So finally entire flow goes like this
User Logs In
The user logs in by providing valid credentials.Backend Generates Tokens
After successful authentication, the backend sends Access Token and Refresh Token to the user.Accessing Protected Routes
Now, whenever the user wants to access any protected route, they send the Access Token with each request.Access Token Expiry
When the access token expires, the backend responds with a 401 (Unauthorized) error.Frontend Refresh Logic
On receiving the 401 error, the frontend triggers a logic where it sends the Refresh Token to the backend.New Tokens Generation
The backend verifies the refresh token and generates new Access Token and Refresh Token.Tokens Sent Back to User
The backend sends both new tokens to the user, and the same process continues…If we want to add more security layers over this, we can do that — we will see those in upcoming articles.
Thank you for reading😊