Cache JWKS in Lambda memory vs in temp

Question

I currently am retrieving a JWKS keys using the Auth0 JWKS library for my Lambda custom authoriser function.

As explained in this issue on the JWKS library, apparently the caching built into JWKS for the public key ID does not work on lambda functions and as such they recommend writing the key to the tmp file.

What reasons could there be as to why cache=true would not work?

As far as I was aware, there should be no difference that would prevent in-memory caching working with lambda functions but allow file-based caching on the tmp folder to be the appropriate solution.

As far as I can tell, the only issues that would occur would be from the spawning of containers rate-limiting JWKS API and not the act of caching using the memory of the created containers.

In which case, what would be the optimal pattern of storing this token externally in Lambda?

Answer 1

There are a lot of option how to solve this. All have different advantages and disadvantages.

First of, storing the keys in memory or on the disk (/tmp) has the same result in terms of persistence. Both are available across calls to the same Lambda instance.

I would recommend storing the keys in memory, because memory access is a lot faster than reading from a file (on every request).

Here are other options to solve this:

1. Store the keys in S3 and download during init.
2. Store the keys on an EFS volume, mount that volume in your Lambda instance, load the keys from the volume during init.
3. Download the keys from the API during init.
4. Package the keys with the Lambdas deployment package and load them from disk during init.
5. Store the keys in AWS SSM parameter store and load them during init.

As you might have noticed, the "during init" phase is the most important part for all of those solutions. You don't want to do that for every request.

Option 1 and 2 would require some other "application" that you build do regularly download the keys and store them on S3 or a EFS volume. That is extra effort, but might in certain circumstances be a good idea for more complex setups.

Option 3 is basically what you are already doing at the moment and is probably the best tradeoff between simplicity and sound engineering for simple use cases. As stated before, you should store the key in memory.

Option 4 is a working "hack" that is the easiest way to get your key to your Lambda. I'd never recommend doing this, because sudden changes to the key would require a re-deployment of the Lambda, while in the meantime requests can't be authenticated, resulting in a down time.

Option 5 can be a valid alternative to option 3, but requires the same key management by another application like option 1 and 2. So it is not necessarily a good fit for a simple authorizer.