Usage of Session Token and JSON web Token

This article explains, what is the session token? and what is the JSON web token? and what is the usage of both the tokens?. Before explaining the tokens let me explain why we move to token concepts while implementing websites.

You all know that what the website is? Right!. Technically saying we are sending HTTP requests from the client (browser) to the server then the server returns the HTTP response based on the request.

HTTP - Hypertext Transfer Protocol is used to communicate between web clients and web servers. It is a stateless protocol which means it doesn't maintain the session or doesn't keep the information of the previous requests.

For example, if the website serves the static pages then there is no need for information saved in the session and the server also doesn't need any info from the client to serve the pages.

In the example above the user sends the HTTP request or URL from the browser and the server receives that request and returns the HTTP response or corresponding HTML file to the browser. Here the website is having two static pages P1 and P2. So anybody can access it and the server doesn't want to remember the previous request and all.

Now if the website is dynamic and the pages are served based on the user information then definitely we need to send some info of the user from browser to server to access those dynamic pages.

Let me explain very clearly, For example, you all came across the banking website. Right! in that you see your account information, transaction history, Loan offers, etc. You can't see the other person's info right but do you think that how this will work?. After login into the banking site how the server identifies you and serve the pages for you?.

After logging in to the banking website some info of the user that sends from the browser to the server. Like Hey! server am so and so coming from the request please provide the pages for myself then the server validates and serve the pages based on that user info.

How does the user information send from the browser to the client? and how the client handles the information? This is the place Session Token and JSON web Token comes into the picture.

Usage of Session Token in Website Development

A session token is an encrypted string value that is the reference of logged-in users. Once the user logged in successfully then the server shares this token with the web client to send the subsequent request along with this token.

Let's take a banking website example again. Once the user logged into the banking website the user's information is saved with the reference of Session ID then the same shared with the Web client (Browser). The browser saves that Session ID in a cookie or local storage and passes that with the header to every subsequent request.

Based on the Session ID the sever validates you and provides the information for you. Once the session vanishes or log out from the website then you can't access the pages of the website.

Drawbacks of Using Session Token

Normally the modern websites are running behind the load balancer to increase the speed of the website. There are multiple servers are running behind this load balancer. At this point, there is no meaning in using Session Tokens. Let me explain how? with the example below.

In the above example, three servers are running behind the load balancer. When the request comes from the browser the load balancer decides which server is going to handle this request based on the load of the server.

The load balancer routes the request to the server always which is having a low level of load which means it doesn't route the request to the same server. This is the place the server doesn't know the previous transactions.

For example, the login request comes to the load balancer then the load balancer sends that request to server S1. The server S1 authenticates the user successfully and registered the user info with Session Token and shares that to load balancer and the load balancer shares the same to the Web Client.

Now the web client sends another request with that Session ID to the load balancer. Now the load balancer route the request to server S2. Server S2 doesn't know the Session ID and can't fetch the user info because that Session ID is registered in server S1 and that only knows the Session ID.

This is the biggest drawback of using Session Tokens. When multiple servers are running behind the load balancer they don't share the Session ID with each other. To overcome this issue we can use Shared Cache Concept like Redis.

Redis is like a server that is used to share the session and the session is available to all the servers which are running behind the load balancer. So this will overcome the issue of using the load balancer technique.

Again this also has the drawback like when the Redis goes down then all the Sessions have vanished. There is a solution for this also. We can use Sticky Session Pattern instead of Redis to overcome this issue.

Sticky Session Pattern is the concept that resides inside the load balancer. I mean the load balancer itself remembers to route all the requests to the same server. For example, the server S1 authenticates the login request and shares the Session ID to the load balancer then the load balancer remembers that and routes the subsequent request to the same server S1 for all the time.

This also becomes more load when the request comes to the same server right. Here JWT (JSON Web Tokens) comes into the picture to overcome this issue.

Usage of JSON Web Token in Website Development

JWT - JSON Web Token is an encrypted string value that holds the user information. This string value contains three parts of encrypted JSON value which are separated by a dot. The three parts are Header, Payload, and Signature. The sample JSON web token is below.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Once the authentication is successful then the server shares this token to the web client and the web client stores this token in a cookie or local storage and sends it with the header for the subsequent requests.

Now you may ask that Session Token and JSON Web Token both as a string value which is passed from client to server. Then how it differs from each other and how it will overcome the issue of shared sessions of servers which are running behind the load balancer.

The only difference between both the token is Session Token is just a reference of user information and not the information of the user but the JWT token holds directly the user information. Session tokens are saved in the server session but here there is no concept of storing.

JWT token is created by the server with the encrypted value of user information with a valid signature. This signature is generated with some secret key which server only knows by using some algorithm. Finally JWT token is having the encrypted format of user information with a signature.

So any server which is running behind the load balancer can decrypt the JWT and validate the signature by using the same secret key with the same algorithm. Here there is no need for shared sessions between the servers. Each server is capable of doing authorization individually for all the subsequent requests.

Hope you understood the concepts of Session Token and JSON Web Token. In the next article let me explain the structure of JWT in detail and how it will be used in spring security. Thanks!. Keep Reading!.