My favorite thing about innovative mechanisms used in web infrastructure to deconstruct hitches is how they usually have very similar themes to our day-to-day actions.
The dilemma being solved in this scenario would be http's inability to remember anything. Much like a patient with amnesia, servers do not remember a single thing about users who have repeatedly sent a request. It would be like having to refill a hospital form every single time you visited, instead of the receptionist entering your name into the database to verify whether you had been at the hospital previously and in the case that you were found, who you are.
In a bid to eliminate this flaw, the initial remedy happened to be one synonymous to a coat rack ticketing system used in various stores where customers are usually not allowed to take in their coats with them. So the server would a generate an id for a user and store information about that user to that particular id, inherently keeping a logbook of all the users. Whenever the user wanted to perform an action, the server would look through the logbook for the user's id in order to be certain that the user could be allowed to perform certain tasks.
But of course, akin to everything in life, change is constant and more so for the purpose of efficiency and that is how json web token came about. If I were to liken JWT to something, I would say the letters in game of thrones. A JWT is called "stateless" because in contrast the logbook we spoke about earlier, It has no way of storing the details about users on the server. This is because JWT hands you a signed letter(or one with a sigil like in game of thrones) with which you bring with you. So at every stop (where you would presumably perform an action) you would show the JWT and you are would now be allowed to perform the action or not.
This proverbial letter consists of three parts namely ; the header, the payload or body and the signature. The header usually contains a title which would say "This is a json web token" (rather mundane if you ask me). The payload would contain details about the user e.g, user id, user name, user role, and so on. And finally the signature which can not be replicated without the server's secret key is made using the payload and the header.
One mistake that is often made when understanding the concept of a JWT is thinking that the payload is encrypted. In truth, the payload of a json web token is simply Base64 encoded, which means the characters are scattered around. In fact, if the JWT was intercepted anyone could decode it and see all the details about the user. It is for this very reason that we are advised to store sensitive tokens in httpOnly cookies to avoid the info being read via JavaScript in the event of an XSS attack. We are often advised to go a further step to hash the passwords stored in the database using bcrypt incase of database breaches.
JWTs are also primarily used for two reasons; authorization and authentication. Authentication is simply checking to see that you are who you claim to be as a user, while authorization is checking to see where or what you are allowed into as a user.
So in the future whenever you come across the use of JWT in your code, you can say that code imitates life, and the systems we engineer can very well be recognized in our day-to-day routines we undertake as people.
