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.
