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. (1)
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 (
One important thing to know about cookies is that they don't identify users. They rather associate the terna data - client - server/path. (3)
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. (2) 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.