Web security has turned into a major topic, it plays an important role in building applications that are secure, and don’t suffer external attacks like XSS. Over the years, web security has evolved drastically. It began with sessions, and is now based on tokens. In this post, you will read about the transition, and how web security is handled nowadays.
Cookies are small pieces of data, shared by a server with a client, who is accessing or logging into a service offered by the server over the web. The server uses “set-cookie” tag for inserting the cookie into the response.
Once the user has successfully logged into the server, every request sent to the server from the client will have either the session id, or a token, which is saved in the cookie.
An Analog to Cookies
You can imagine Cookies as an Employee ID card. When you join a company, you will receive the ID card, with an Employee ID. Every time you wish to enter the company, the ID needs to be presented at the security gate. And, when you leave the company for good, you will no longer be related to the ID.
In the beginning, the server used Session ID to authenticate every client, logging into the server. Once the authentication is done, the Session ID is shared by the client with the server, for authorization. Both authentication, and authorization are different use cases for the Session ID.
An Analog to Session
Looping into our previous example, the Employee Data and the ID generated is managed by the company. Details about the employee are linked to the ID, and they are stored securely. The overall duration of the link, and the way the link is destroyed depends on the company’s policies. As long as an employee works for the company, it would translate into a Session.
#jwt-token #authentication #cookies #sessions #web-security