What is this new JWT thing?
Does it replace the usual session-cookie?
How complicated is this thing called JWT?
JWT , "J-awt" as they call in some circles, in a layman's language is a mechanism to store some arbitrary data, but is so structured that the JWT can also authenticate that the data has not been changed by a third party ( remind's me of block-chain, but it is a distributed ledger and thankfully JWT is not as complicated as that ).
Once we know the data integrity cannot be compromised, a server could issue it to the client and the client henceforth could use it for dealing with server, and providing the JWT to the server in any communication is a simple way of client to claim the rightful resources. One can imagine JWT to be some sort of access card given to employees by the employer during the on-boarding. After that, employee could use it to access the office and the other places as designated by the employer.
Isn't this what was session-cookie was also designed to do. Uhmm yes, but here we need to digress , a cookie is a mechanism for a HTTP-Client-Server to keep some underlying information. It is send as a part of every transmission once it is set. Session-Cookie is the name given when we used to store session-token in the cookie. The session-token used to be a token with a database entry and would have permissions listed against it. Just like the employee badge. Every time access request comes, the session token is extracted from the cookie, compared against the database ( or some storage ) and authorized. This is a tedious process since if every access is validated against DB , it would form the bottleneck. This is the kryptonite for session-tokens ( or session-cookies ).
JWT evolved to solve this by not needing the server to say hello to the DB for every single request. It could easily hash out the validity and find the authenticity. So the requests are not throttled by a DB, but this can be beneficial to a micro-service based architecture where every micro-service could understand the token and need not check up with a separate auth service to check the authenticity of the token. Sounds cool, isn't it?, but there is a drawback, remember - earlier I had said about employee and access-badge?, the session-token is a proper badge. If there is a rogue employee or if someone loses the badge, we can disable it electronically. But the JWT is like a dress/uniform or a name-plate. If some steals ( copies it ), they would also be authorized to do everything that the real user was intended to do. OOPS!
There are some protection which can be done against this problem as well. But that's for a separate blog.
To summarize, JWT provides for scalable way of authorizing clients, session-tokens provides more control. JWT for speed , session-tokens for security.
In the end - JWT can be stored in cookies , and session-tokens can be sent without any cookies.
