JWT or JSON Web Token is an open standard (RFC 7519) which is used to securely transfer information between two parties.
To understand the detail concept of JWT, it’s very important to first know about Session tokens.
Session Tokens are an encrypted unique strings that are used to identify Session Instances. Look at the understandable example below-
Think of a Customer Care Dept. in a city, if a person(A) enters into it who has any queries to speak with representatives. Initially a person would speaks about all his problems and queries, then normally the care dept. would note down all the queries that particular customer has on a single piece of paper or in a database, and the point here is that, they would provide the customer with a Customer ID no. or Case ID no. which contains all information about queries or problems, as this would make customer care dept. to search for particular case in much faster way next time the same customer arrives for the solution.
Now Let’s think the same procedure with Clients and Servers —
Think of any website that contains Registration forms, here once the user enters into particular website and registers with his/her data. This data directly hits the server and on the server sends a token for that particular browser. The token is stored in the cookie of the browser and can be valid until the user logs off or until any time period. This token validates and helps the user to access all the subsequent requests made by him/her.
This method of validating and authorizing the user was much proper, but there was a key drawback to use session tokens. Let’s look at a example of Online Banking Systems, let’s imagine a scenario here, if a person logs in with his/her credentials on any banking website, Server(A) would pass a session token to the browser and hence here only Server(A) would authorize the current user as it has valid session token to match with its corresponding. And if any subsequent request would pass to Server(B), there would be conflict as Server(B) doesn’t know about historical tokens. This drawback gave birth to JWT.
JSON Web Tokens —
Let’s dive directly into the same example —
If a person, has problems to ask for a customer representative, the customer would visit the Care dept. and similarly rept. would note down all the problems with a Signature or Customer ID, so that if next time a customer enters the dept., a representative must identify the problems once they verify the Signature or Customer ID. But in this case, the document would be handover to customer, where the customer must bring the document whenever they enters dept. This saves the complexity that a rept. would be facing at the time of searching for particular customer Case ID and lot more other beneficial things.
Now Let’s think the same procedure with Clients and Servers —
In this case, Once a user registers or logs in with his or her credentials, a server generates a JWT token and assigns it with the data, and passes it to client-side. This token can only be verified by server, which on the client side it is stored in cookies of browsers and helps the browser or client to access all subsequent requests in no time. This brings lot of Reliability to users and helps in the process of Authentication.
Structure of JWT-
There must be 3 parts in which JWT structure is Divided —
Headers
Usually, headers are first part in JWT’s which consist of Algorithm used to encode JWT and type of the token which is JWT by-default.
- Payload Payload section is the middle part of JSON web tokens, which consists of User Data, which is passed between Client and Server.
- Signature Signature is the third part of the JWT which is created by server, and used to validate the requests, done by the user. To create the signature, the base-64 encoded header and payload are taken, along with a secret key and signed with algorithm specified in the header.
This Entire JWT is embedded in a type of string and these 3 parts are separated by dots(.).
Thank You!