Is there any HTTP Caching mechanism/tools that allow the caching of data for authenticated users within an organisation/segment?

The Cache-Control header basically controls: When some data should be considered fresh/stale Whether the data should be stored in public caches. There are also related caching headers such as Vary which is used to nudge whether two pieces of content should be considered equal for purposes of caching. Not only your browser, but tools like Varnish and CDNs will use these headers to cache responses, prevent a request from having to go to the origin server. What's quite attractive about these tools is that they are somewhat easy to implement, a service just needs to add cache headers and CDNs and caching tools respect the headers. However, this only really seems to work for public data (eg. static assets), as soon as you add the private directive, the tools are going to start ignoring it. There are plenty of scenarios where you might want some kind of caching for authenticated users, for example: There is some kind of image sharing platform, that is for authenticated users only.* Think a tool like Jira, where you might have a thousand users in an organisation, you don't want to have return to the database each time one of them wants to see a list of tickets. *I will note that for static assets you can get private like behaviour by simply assigning each asset a unique, uniterable ID. For example Github does this with images that are attached to issues. It seems to me that at the point that you have authenticated users, any caching behaviour needs to be bespoke and occur in the application layer. Whereas I can imagine a caching tool that does something like the following: For any given request, look for a cookie (or request header) with name 'x', expecting its value to be JWT Validate the JWT against a known public key (optionally, if there were multiple segments) inspect the JWTs contents to determine what segment the user belongs to. Does such tooling exist? If not, is there an obvious reason why this isn't done?

Apr 28, 2025 - 09:32

The Cache-Control header basically controls:

When some data should be considered fresh/stale
Whether the data should be stored in public caches.

There are also related caching headers such as Vary which is used to nudge whether two pieces of content should be considered equal for purposes of caching.

Not only your browser, but tools like Varnish and CDNs will use these headers to cache responses, prevent a request from having to go to the origin server.

What's quite attractive about these tools is that they are somewhat easy to implement, a service just needs to add cache headers and CDNs and caching tools respect the headers.

However, this only really seems to work for public data (eg. static assets), as soon as you add the private directive, the tools are going to start ignoring it.

There are plenty of scenarios where you might want some kind of caching for authenticated users, for example:

There is some kind of image sharing platform, that is for authenticated users only.*
Think a tool like Jira, where you might have a thousand users in an organisation, you don't want to have return to the database each time one of them wants to see a list of tickets.

*I will note that for static assets you can get private like behaviour by simply assigning each asset a unique, uniterable ID. For example Github does this with images that are attached to issues.

It seems to me that at the point that you have authenticated users, any caching behaviour needs to be bespoke and occur in the application layer.

Whereas I can imagine a caching tool that does something like the following:

For any given request, look for a cookie (or request header) with name 'x', expecting its value to be JWT
Validate the JWT against a known public key
(optionally, if there were multiple segments) inspect the JWTs contents to determine what segment the user belongs to.

Does such tooling exist? If not, is there an obvious reason why this isn't done?