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

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.

Properties of a Cookie:

1. These are “string” type data structures.
2. Cookies are stored in the client side.
3. Cookies are never safe, mainly because they are not encrypted, and can be read easily.
4. Cookies are small pieces of information, less than 4kB in size.

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.

Session

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.

Properties of a Session

1. Maintained at the server
2. Sessions are encrypted, and stored safely in the server. They are stored only in a single server at a time.
3. Sessions have an “Object” data structure.
4. The lifetime of a session depends on the server coding.
5. Sessions are generally an overhead. They are expensive to create, and store.

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