我正在使用Cognito，API网关和授权者。授权者配置为缓存5分钟以提高性能。我觉得这是一个不错的功能。
我知道授权者是将身份验证逻辑放在一个地方的好方法，并且应用程序可以假定用户已被授权。但是，我对此表示怀疑。
渗透测试报告建议，一旦注销，令牌就不能使用。因此，为了安全起见，我不应该启用授权者缓存吗？这也意味着所有经过身份验证的API都要经过一个lambda授权者的开销……
从编码的角度来看，使用难以进行端到端测试的授权者真的是一个好主意吗？我可以将lambda函数作为一个单元进行测试。但是对我来说更重要的是它们已连接到正确的API。我目前无法看到可以轻松测试的方法。
另一个问题是查看代码，我再也无法轻易分辨出需要什么授权……我必须查看应该附加哪个授权者（例如CloudFormation），然后查看lambda代码本身。
使用授权者有什么好处吗？或实际上最佳做法是什么？
答案 0 :(得分：1)
为了安全起见，我不应该启用授权者缓存
如果您有严格的安全要求（例如，令牌失效后所有请求都将失败），则将需要关闭授权者缓存。请参阅https://forums.aws.amazon.com/thread.jspa?messageID=703917的答案：
当前，授权者缓存只有一个TTL，因此在您呈现的方案中，API令牌将继续为缓存TTL返回相同的缓存策略（生成200），而不考虑令牌是否已过期。您可以将缓存TTL调低到您认为合适的级别，但这是在授权者级别设置的，而不是基于每个令牌设置的。
我们已经在考虑自定义授权者功能的更新，并且在我们迭代该功能时，一定会考虑您的反馈和用例。
这也意味着所有经过身份验证的API都要经过Lambda授权者的一项开销...
确实如此。但是，实际上，我的团队在Lambda冷启动和ENI附加方面比在性能方面要付出更多的努力，因此授权人添加的开销最终可以忽略不计。这并不意味着性能下降是无法衡量的，但是与直接将授权者代码放置在Lambda中相比，最终导致延迟增加了毫秒级，这在我们的应用程序中很有意义。与之形成鲜明对比的是，Lambda冷启动通常可能需要30秒钟。
从编码的角度来看，使用很难测试端到端的授权者真的是一个好主意吗？
在许多基于面向服务的体系结构上构建的应用程序中，您将拥有跨多个代码库且只能在已部署环境中进行测试的“端到端”方案。此级别的测试显然是昂贵的，因此您应避免使用较低级别（单元，集成等）测试可以涵盖的测试功能。但是，测试应用程序的内聚性仍然非常重要，而您将需要进行此类测试的事实并不一定会对SOA产生重大影响。
我可以将Lambda函数作为一个单元进行测试。但是对我来说更重要的是它们已连接到正确的API。我目前看不到可以轻松测试的方法。
如果您正在考虑多个授权者，一种测试正确授权者已连接的方法是让每个授权者将指纹向下传递到端点。然后，您可以ping端点并使它们返回运行状况检查状态。
例如，
[ HTTP Request ] -> [ API Gateway ] -> [ Authorizer 1 ] -> [ Lambda 1 ] -> [ HTTP Response ]
Payload: Payload:
user identity status: ok
authorizer: 1 authorizer: 1
在实践中，我的团队每个服务只有一个授权者，这使得对该配置的测试变得不重要（我们只需要确保应该保护的端点是安全的即可）。
另一个问题是。查看代码，我再也无法轻易分辨出需要什么授权...我必须查看应该附加哪个授权者（例如CloudFormation）以及Lambda代码本身。
是的，这是事实，在团队中使用AWS基础设施时，巨大的解耦环境的性质是很难在本地进行测试的，这是我的团队最大的困扰之一。但是，我认为在处理AWS空间时，这主要是学习曲线。整个开发社区对于AWS公开的许多概念（例如代码或微服务之类的基础设施）来说还相对较新，因此与传统的整体开发相比，我们在该领域缺乏工具和教育。
这是适合您的应用程序的正确解决方案吗？没有深入的分析，我无法告诉您。在更广泛的社区中，有很多观点都是双向的，但是我想向您指出这篇文章，特别是对于列出的谬论：Microservices – Please, don’t。使用微服务是因为您已经为它们开发了可靠的用例，而不必只是因为它们是计算机科学中的最新流行语。
使用授权者有什么好处吗？或实际上最佳做法是什么？
我的团队使用AuthN的授权者（通过自定义身份验证服务），并在单独的Lambda层上（通过不同的自定义身份验证服务）处理AuthZ。这对我们的体系结构非常有益，因为它使我们能够将通常极其复杂的特定于对象的安全规则与简单的身份问题隔离开来。您的用例可能有所不同，我当然不会声称知道最佳实践。但是，我将向您指向API Gateway Authorizer examples，以获取有关如何将该服务集成到应用程序中的更多想法。
好运。