Hello everyone, in today’s article, you and you will learn about JWT.

What is JWT?

JWT (Json Web Token) is an open standard (RFC 7519) that defines how to securely transmit information between parties as JSON object. This information can be verified and marked with confidence thanks to its “signature”. JWT’s signature will be re-encrypted using HMAC or RSA .

Simply put, it is a json-format encoded string containing information that allows senders to be verified between different services.

When should i use JWT?

• Authorization : This is the most common scenario for using JWT. With authorization, we verify that the username and password are valid, and then log the user into the system. When the user is logged in to the system, the requests sent to the server belong to the user that contains additional JWT codes, allowing this user to have access to the system, access routes, services and accounts. If there is such a token, it is necessary to obtain an authorization.
• Communication : We can securely transmit information and recognize who the sender is using its “signature” portion. Moreover, JWT’s signature is created by combining both header and payload, so we can easily recognize if that signature is fake or not.

Session Id vs JWT

• Session Id : With traditional web, we usually use session to grant user permission. When users log into the system, they will be given unique session id. This Session Id is stored in a secure cookie in the user’s browser and in the server’s memory. We continue to use the same session with every request so the server knows the user is authenticating. For every request, the session id in the cookie matches the session id in the server memory to verify that the user is authorized.

• JWT : When we deploy the system with JWT to authorize the user, once the user has access to the system, we will create a unique JWT key for that user. Then save JWT in local storage or browser cookie but not on server side. For each request sent to the server, the request will be accompanied by jwt to be decrypted and verified that the user was authorized. If there is something wrong with the token, it will be rejected immediately.

This approach is quite beneficial because we can reduce server-side memory, which is very suitable for small systems.

So what if our system gets bigger and needs to be scaled up:

** With Session Id **

As shown in the picture above, what if the user is logged on with server 1 and this server has stored the session in its memory, when that user makes another request and the load balancer redirects the request to the machine? server 2 but server 2 does not store that user’s session information.

The user will inevitably be logged out of the app and asked to log in again, which will result in a bad experience for the user. And to counter this, we will use the cache.

Now that the login session is stored in this cache, both servers can check if this session exists and can use it to verify and grant them access to the application. use.

While the cache fixes the above problem, this solution becomes very expensive in production environments, because:

• It takes a lot of RAM, CPU, and Cache to keep track of all those sessions as well as process requests smoothly.
• Maintain the cache regularly to make sure there are no invalid seesion.
• In the event of a server failure, all sesions will be lost if not synchronized with the cache.
• Disabling the user will become more complicated.
• High storage costs.

With JWT

Instead of using session id in cookie and having to match session in server memory, we use JWT to do this. When the user logs in to the application, the server will not create the session id and store it in the previous memory, instead it creates JWT and encrypts it with its own encryption mechanism. This way, the server will know if this code is changed it will become invalid. This is always checked as it is signed by the server encryption mechanism.

In short, it looks like this: JWT:

• Nothing is stored on the server at all, stored in the client machine inside JWT.
• Encrypted and signed by the server.
• Token contains all user information

Session Id:

• Session Id is stored on the server.
• Encrypted.
• Session Id is a reference to the user.
• The server needs to look up user information and check it as required.

Structure of a JWT

The JWT consists of three parts and is separated by a period (.):

• Header
• Payload
• Signature

A JWT usually looks like this.

xxxxxx.yyyyyyy.zzzzzzzz

Header:

The header usually consists of two parts:

• Token type, default is JWT,
• The algorithm used for encryption, such as HMAC SHA256 or RSA.

This Json is encoded Base64Url to form the first component of JWT.

Payload:

The second part of the token is Payload, which contains claims. Claims are an entity (usually the user) and additional data. There are three types of claims: registered , public , and private claims .

Registered claims : This is a set of predefined metadata that is not required but recommended to provide a complete and valid set of claims. One of them is: Iss (issuer), exp (expiration time), sub (subject), aud (audience), …

Public Claims : Recognized and widely used by the community.

Private Claims : These are custom claims that are created to share information between parties that agree to use them and are not registered claims or public claims.

Signature:

As a header encoded string, the payload along with a secret string follows the following principle:

Signature is used to verify the message has not been altered during execution, in case the tokens are encrypted with the private keys, it can also verify that the JWT sender is that person.

End :

My post here is over, if you find it interesting and useful, please Like , Share and Upvote

Thanks everyone