When setting up (hmac) token based authentication for resources, I effectively end up having a changing element in the URL - the token. As a consequence, the browser/client can no longer cache the resources, since the URL is always slightly different and there is no way (that I know of) to tell the browser "ignore this part of the URL when doing a cache check).
At the moment we build the URLs with the token in a service that answers with a 302 redirect, so we can at least cache the redirect for a certain amount of time. However that only solves the problem partially. Let’s say the token is valid for 60s. I would now set the redirect caching max-age to 60s as well. If the browser gets refreshed within those 60s, it will use the redirect location from the cache, get the resource url and reuse its content from the cache as well.
However, after those 60s the target resource might also still be in the cache and retrieving it again is a waste of bandwidth. On the other hand, if I cache the redirect longer, it might be that the browser doesn’t actually have the target resource anymore and would now get rejected (403) since the token is expired.
Is there a preferred pattern to solve this? The goal should be that resources are protected but still (effectively!) cached client-side.