8

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!

10

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; and more specifically, for holding the state in 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 (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. (3)

We use to associate cookies with files because, during the early days of the web browsers, these 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 in the server-side. (2) In such environments, 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 not seriously aware about security. At least not the regular user.

On the other hand, to attack the 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 issuer.

Although they use to contain the user ID, 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.

  • Id note that some, like default Ruby on Rails config, stores the entire "session" object in a cookie (these days normally encrypted), which may just simply contain something like user_id for a logged in user. – Fire Lancer Sep 4 '17 at 19:15
5

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:

enter image description here

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.

  • JWTs are not normally stored in cookies in my experience. They could be, but more often I've seen them in their own headers (or often the Authorization header) on the way to the server and stored either in memory or in Local or Session storage on the client. – Paul Sep 4 '17 at 13:13
  • 1
    @Paul regarding local storage. It depends on the client. Not all the clients and not all the version of the most used clients support web storage. Take a look here. If they are, is preferable to make tokens seasonal. But, if our clients don't support local storage; Httponly cookies + SSL + client fingerPrints provide us with a fairly secure implementation. – Laiv Sep 4 '17 at 13:43
  • @Laiv I'm not disagreeing with you; just that Samuel said that "The token is stored in a cookie", and I was just trying to observe that this is not always the case. – Paul Sep 4 '17 at 16:23
  • @Paul I changed to read "... may be stored in a cookie" – Samuel Sep 4 '17 at 18:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.