Caching strategies for authenticated data



  • Kevin

    Good question, Ian. I've been working on a similar project. The route we're going is a mix of a backend request to our authentication/authorization service (via something like + Vary and ESI, where it makes sense.

    Although all of our requests are "authenticated" via an access token or API key (whether logged in or logged out), most of the responses are the same across users. The variations or user-specific uniqueness comes down to:

    • Response data can differ by requesting IP/country
    • Logged in requests contain a response header with the user id
    • Some responses include user-specific embedded data

    For the first case, we are using Fastly's GeoIP feature to set a header and then Vary on it. For the second, our auth backend request returns this header value. For the last, we're using ESI (

    Would be curious to hear solutions others are taking here!


    Comment actions Permalink
  • Ilya Kaplan

    You can leverage Fatly's cryptographic functions, like digest.hmac_sha256(key, message), have shared secret key between your servers and VCL and use any user's info as message - id, email, id+password, etc. Generate it on server and store result in user's cookies, and compare it in VCL every time you want to verify authentication and redirect him to some error/login page if failed.

    If you have different access levels, it might get complicated. Yet, you can still have it in single cached bucket like this: Have separate cookie that lists API's that user can access. Have authentication cookie = hmac(secretkey, userid + api-list) When accessing some API check that it's in the API list cookie AND that and verify authenticity of API list by comparing HMAC.

    The only problem with this approach, is that there's no easy way to remove access from some API.

    Comment actions Permalink
  • Amir Yalon

    [quote="Ilya_Kaplan, post:3, topic:946"] The only problem with this approach, is that there's no easy way to remove access from some API. [/quote]

    If you include a timestamp in the authenticated hash, you can limit how long a token is valid before having to get a new token. Combine this with @kevin’s model of lightweight re-authorization service, and you won’t have to re-generate the content in the backend for every token renewal.

    Comment actions Permalink

Please sign in to leave a comment.