我目前正在使用Auth0 JWKS库为Lambda自定义授权程序函数检索JWKS密钥。
正如本期JWKS库中所解释的那样，显然JWKS中为公钥ID构建的缓存对lambda函数不起作用，因此他们建议将密钥写入tmp文件。
cache=true不起作用的原因是什么？
据我所知，应该没有什么区别可以阻止内存中缓存使用lambda函数，但允许tmp文件夹上基于文件的缓存成为合适的解决方案。
据我所知，唯一会发生的问题是容器速率限制JWKS API的生成，而不是使用创建的容器的内存进行缓存的行为。
在这种情况下，将此令牌外部存储在Lambda中的最佳模式是什么？
如何解决这个问题有很多选择。所有这些都有不同的优点和缺点。
首先，将密钥存储在内存或磁盘上(/tmp(在持久性方面具有相同的结果。两者都可以在对同一Lambda实例的调用中使用。
我建议将密钥存储在内存中，因为内存访问比从文件中读取要快得多(每次请求时(
以下是解决此问题的其他选项：
- 将密钥存储在S3中，并在初始化期间下载
- 将密钥存储在EFS卷上，将该卷装载到Lambda实例中，在初始化期间从卷加载密钥
- 在init期间从API下载密钥
- 使用Lambdas部署包打包密钥，并在初始化期间从磁盘加载它们
- 将密钥存储在AWS SSM参数存储中，并在初始化期间加载它们
正如你可能已经注意到的；在初始化期间；阶段是所有这些解决方案中最重要的部分。你不想对每个请求都这么做。
选项1和2将需要一些其他的"；应用程序"；您构建的会定期下载密钥并将其存储在S3或EFS卷上。这是额外的努力，但在某些情况下，对于更复杂的设置来说可能是个好主意。
选项3基本上就是您目前已经在做的事情，对于简单用例来说，它可能是简单性和声音工程之间的最佳折衷。如前所述，您应该将密钥存储在内存中。
选项4是一个工作"；破解"；这是拿到Lambda钥匙的最简单方法。我从不建议这样做，因为密钥的突然更改需要重新部署Lambda，而与此同时，请求无法进行身份验证，从而导致停机时间。
选项5可以是选项3的有效替代方案，但需要由另一个应用程序(如选项1和2(进行相同的密钥管理。因此，它不一定很适合一个简单的授权者。