Understanding the Need for JSON Web Token (JWT)

• JWT stands for JSON Web Token
• It is pronounced as JAWT
• It is Open Standard — RFC7519
• JWT makes it possible to communicate securely between two bodies
• JWT is used for Authorization

Video

This tutorial is explained in the below Youtube Video.

Authorization

In order to understand authorization, we will be taking an example of user interaction with Gmail. Consider a scenario where a user wants to access their Gmail inbox page. This will involve user interaction with the Gmail server. For this, the user will be sending HTTP requests to the Gmail server and in response will expect the response from Gmail Server.

The steps will be as follows:

• The user will send an HTTP request to the Gmail server with a url/login. Along with this request, the user will also be sending the username and password for authentication.
• The Gmail server will authenticate this request. If it is successful, it will return the Gmail inbox page as response to the user.
• Now, suppose the user wants to access their sent mail page. They will again send a request to the Gmail server with url/sentmails. This time, they will not be sending the username and password since they have already been authenticated in the first request.
• The user expects Gmail to return the sent mail page. However this will not be the case. The Gmail server will not return the sent mail page but will instead not recognize the user.

The reason for this is HTTP is a stateless protocol. As the name suggests, no state is maintained by HTTP. So in case of HTTP protocol for the Gmail server, each request is from a new user. It cannot distinguish between new and returning users. One solution for this issue could be to pass a username and password along with each request, but this is not a good solution.

Once a user has been authenticated. For all subsequent requests, the user should be authorized to perform allowed operations

Authorization can be implemented using:

• Session Management
• JSON Web Token

Using Session Management for Authorization

In the case of Session Management, once the user has been authenticated, the Gmail Server will create a unique session Id. Corresponding to this session id it will store in memory all the user information that is needed by the Gmail server for recognizing the user and allowing it perform operations.

Also then for all subsequent requests and response, this session id will also be passed. When the server receives a request, it will check the session id. Using this session id, it will check if there is any corresponding information. It will then allow the user to access the resource and return back the response along with the session id.

Drawbacks of Session Management for Authorization

• Session Id is not self-contained. It is a reference token. During each validation, the Gmail server needs to fetch the information corresponding to it.
• Not suitable for microservices architecture involving multiple APIs and servers

Using JWT for Authorization

We make use of the JWT for authorization so the server will know that the user is already authenticated and so the user does not need to send the credentials with each and every request.

Advantages of JWT Authorization

• JWT is self contained. It is a value token. So during each validation the Gmail server does not needs to fetch the information corresponding to it.
• It is digitally signed so if any one modifies it the server will know about it
• It is most suitable for Microservices Architecture
• It has other advantages like specifying the expiration time.

In the next tutorial we will be Understanding JWT Structure.