cookie vs. session vs jwt

Question

I am reading up on authentication/authorization in web applications. Could anybody confirm/correct my current knowledge?

• Cookies: in their early version, a text file with a unique client Id an all the other information needed about the client (e. g. roles)

• Session: only the unique client id is sent in a file (also called cookie), everything else is stored on the server

• JWT: everything is stored in the token (which could also be stored in a text file, which is also called cookie)

Thanks for any feedback!

Answer 1

Cookies: in their early version, a text file with a unique client Id an all the other information needed about the client (e. g. roles)

Cookies are tuples key-value originally addressed to retain data related to the client activity. This retention is what we know as session or application state. Fundamentally, they were made for holding the state of web applications; more specifically, the state on the client-side. ⁽¹⁾

Cookies are usually set by the server via response headers (Set-Cookie key=value). However, they can be set by the client too. For example, by DOM (document.cookie).

One important thing to know about cookies is that they don't identify users. They rather associate the terna data - client - server/path. ⁽³⁾

We usually associate cookies with files because during the early days of the web browsers they had to persist the cookies somehow, being files the most feasible support. Today's browsers store cookies (among other things) in local storages (embedded DBs).

Session: only the unique client id is sent in a file (also called cookie), everything else is stored on the server.

By session, I guess you mean server sessions. As I commented, sessions can be implemented in the client-side too. The difference with client-side sessions is that the data is stored somewhere on the server-side. ⁽²⁾ In such scenarios, what we get is a session id; and we get it in form of cookie. Without the session id, the server would not be able to correlate the incoming requests with the previous activity of the client. (3) For example, the authenticated user, the shopping cart, etc.

In any case, a session ID doesn't necessarily identify a user. It associates a specific application state with a web client. Sessions might or might not contain user data.

In distributed appllications, the session should be serializable for obvious reasons. If they are stored in memory, the in-memory storage (component) should be serializable. A common solution is to store sessions in files. Or in NoSQL DB like Redis.

Regarding security. Server-side sessions are safer than the client-side. Clients are more vulnerable to threats because users usually are unaware of the so many threats they are exposed to. At least not the regular user.

On the other hand, attacking a server-side infrastructure is not trival.

JWT: everything is stored in the token (which could also be stored in a text file, which is also called cookie)

Not really. JWT stores data mainly related to the authorization and the issuer of the token.

Although they use to contain the user ID (sub), we find JWTs that don't identify authenticated users. For example, tokens for guests sessions. The main content of JWTs are claims; items to be checked by the authorization process.

Is important to keep in mind that JWTs are not global storages. The session or the application state still has to be stored somewhere and managed independently.

Regarding JWTs, these are often stored as cookies, although they can be also stored in local storages. Moreover, OWASP community considers the sessionStorage to be the more secure for web browsers. However, it depends on the version of the browser.

---

1: The World Wide Web is meant to be stateless. If we want to build stateless server-side applications, sessions should be stored somewhere in the client-side.

2: Turning the server-side application into a stateful application.

3: Client as application, not as user.

Answer 2

Cookies: in their early version, a text file with a unique client Id an all the other information needed about the client (e. g. roles)

Your definition of cookie doesn't really describe what they do. A cookie is a key-value pair that is set via HTTP response header (Set-Cookie) by the server and stored by clients that support them. Cookies are sent back with each subsequent request (in the Cookie header) for requests matching scheme, host, path, https while the cookie hasn't expired. You can store anything you want in a cookie, and it allows you support state on HTTP's stateless protocol.

An example cookie exchange looks like this:

Session: only the unique client id is sent in a file (also called cookie), everything else is stored on the server

That's pretty much right. A session is data that is stored on the server side about a user's current session. To make this work in a stateless protocol like HTTP the user must send their session ID with each request, so the server can fetch the correct session for the user. The session id is typically stored in a cookie (see above). This is not a different cookie than any other cookie, the data is just the server's ID for the user session.

JWT: everything is stored in the token (which could also be stored in a text file, which is also called cookie)

That's pretty much true. Everything is stored in the token. The token may be stored in a cookie (see above). This is an alternative to server sessions, and it works because the token is signed and verified by the server, so it cannot be altered or forged, and it is safe to store on the client side.