JSON Web Token is the open standard (RFC 7519) self-contained way that will be used to transmit the data securely over different environments as a JSON Object.
JWT is the trusted way of authentication because it is digitally signed and secret using the HMAC algorithm, or sometimes using a public/private key using RSA.
Basically, HMAC stands for Hashed-based Message Authentication Code, it uses some cryptographic hashing technique that provides us with better security.
JWT is part of great authentication and authorization frameworks like OAuth and OpenID, which will provide a great mechanism to transfer data securely.
Why Use JSON Web Token?
- JWT is a good way to securely transmit information between different parties because it is digitally signed, which means we know about the user, like who they are and what they want to do, based on the information they send.
- JWT is an encoded token that adds a signature with a secret key that provides more security.
Structure of JSON Web Token
The JSON Web Token consists of three parts which are used to store user information in the Token separated by dots(.)
It is encoded in Base64Url, which stores user secrets and information in three parts.
The header stores information about the JWT token, like the type of the token and whatever algorithm we use while creating the JWT token.
The payload is the second part of the JWT token and is used to store information about users like claims, roles, subjects, and some additional information related to a user.
A signature is used to check user information that is present in the header and payload and validate things with a secret key and data that is present in a Base64-encoded string. Basically, a secret key is present on the server, which we use while validating the token. That secret key prevents external attackers from cracking the token. So, in this process, an encoded string is created to be used for authentication and authorization.
So, these are the three parts of the token that are present in the Base64Url string, which is separated by a dot and stores secret information about the user for validating users.
Client Server Scenario with JWT token:
You can see in the following diagram how the authentication process works for the client when he wants to access resources from the backend server.
First, the client sends a request to the authentication server with credentials like a username and password.
Then, the Authentication Server will validate that information, and if whatever information is provided by the client is correct and successfully authenticates, the Auth Server will issue the JWT Valid Access Token to the client.
Next, the client sends the first request to the backend server with a valid JWT access token, and the server will provide the requested resource to the client.
Later on, if the client wants to access another resource from the backend server, he will send a second request to the server.
Now, when the client sends the second request to the server to access the protected resource, the token is expired, so the server responds to the client accordingly.
After that, the client again needs to log in and send the client credential to the authentication server to get a new JWT Valid Access Token and store it somewhere on the client side in the local storage and something like that in the Base64Url Encoded URL.
So, this way, the normal authentication process will work.
Client Server Scenario with JWT Refresh Token
The following diagram shows how the JWT Refresh Token will work.
First, the client will send the request to the authentication server with credentials like a username and password.
Next, the authentication server validates the client information and credentials that are correct, and then the server will provide the JWT Valid Access Token and Refresh Token. Then, the client will store that token somewhere on the client side, in local storage or something like that, as per need and requirement.
Later on, the client sends the first request to the backend server to access the protected resources with the JWT Valid Access Token in the header.
Next, the backend server checks the roles and permissions of the user, like the login client is authorized to get the protected resources, and if that is valid, then the backend server provides the requested protected resource to the end user.
In the meantime, the client sends the second request to the backend server to access other resources and services, and if the JWT Valid Access Token is expired, the server will respond to the client as you see in the above image.
When the JWT Valid Access Token is expired, the client sends the authentication request to the Auth Server with an existing Refresh Token to get a new JWT Access and Refresh Token without having to ask the client to log in again.
Next, the server will validate the client information and provide a new access token with a refresh token to the client.
The refresh token has more life than the JWT Valid Access Token.
Also, if the refresh token will get expired then the client needs to provide credentials and get a new access and refresh token in that case.
So, all the above steps are executed continuously while navigating the web application and accessing the new services and resources over the internet.
Why Use Refresh Token?
A refresh token is basically a special key that we use to generate a new JWT access token without having to ask the user to log in again.
Refresh tokens have more life than access tokens. Access tokens have a specified time span, and because of that, the user needs to provide user credentials after a specified time. Hence, to avoid client activities and improve user experience, you can use the JWT refresh token.
Nowadays, we use many streaming platforms and websites to access resources and watch different shows. So, this type of application may use a refresh token scenario; they will ask for user credentials initially, and after that, they will rotate and use a refresh token to get a new access token after a specified time span and improve the user authentication experience.