API 网关授权者和注销（Performance/Security 注意事项）
API Gateway Authorizer and Logout (Performance/Security Considerations)
我正在使用 Cognito、API 网关和授权器。授权者被配置为缓存 5 分钟以提高性能。我觉得这是一个很好的功能。
我知道授权器是将授权逻辑保存在一个地方的好方法，应用程序可以假定用户已经获得授权。但是，我有疑问。
渗透测试报告建议，一旦登出，令牌就不能再使用了。所以这意味着为了安全，我不应该启用授权缓存？这也意味着所有经过身份验证的 API 都将通过 lambda 授权方的一次开销......
同样从编码的角度来看，使用难以端到端测试的授权器真的是个好主意吗？我可以将 lambda 函数作为一个单元进行测试。但对我来说更重要的是它们附加到正确的 APIs。目前我看不出有什么方法可以让我轻松地进行测试。
另一个问题是查看代码，我无法再轻松判断需要什么授权...我必须查看应该附加的授权方（例如 CloudFormation），然后是 lambda 代码本身。
使用授权器有好处吗？或者实际上最好的做法是什么？
For security, I should not enable authorizer caching
如果您有严格的安全要求（例如，一旦令牌失效，所有请求都应该失败），您将需要关闭授权缓存。从 https://forums.aws.amazon.com/thread.jspa?messageID=703917 看到这个答案：
Currently there is only one TTL for the authorizer cache, so in the scenario you presented API Gateway will continue to return the same cached policy (generating a 200) for the cache TTL regardless of whether the token may be expired or not. You can tune your cache TTL down to level you feel comfortable with, but this is set at level of the authorizer, not on a per token basis.
We are already considering updates to the custom authorizer features and will definitely consider your feedback and use case as we iterate on the feature.
It also means all authenticated APIs will have a go through one overhead of a Lambda authorizer...
确实如此。然而，在实践中，我的团队在 Lambda 冷启动和 ENI 附件方面比其他任何性能方面都更加努力，因此我们的授权者增加的开销最终可以忽略不计。这并不意味着性能损失不可衡量，但与将授权代码直接放在 Lambda 中相比，它最终增加了毫秒级的延迟，这种权衡在我们的应用程序中是有意义的。与之形成鲜明对比的是，Lambda 冷启动通常需要长达 30 秒。
Also from a coding perspective, is it really a good idea to use authorizers which are hard to test end to end?
在许多基于面向服务的架构构建的应用程序中，您将拥有跨多个代码库的“端到端”场景，并且只能在已部署的环境中进行测试。此级别的测试显然很昂贵，因此您应该避免测试可能被较低级别（单元、集成等）测试覆盖的功能。然而，测试您的应用程序的内聚性仍然非常重要，您需要此类测试的事实并不一定是对 SOA 的巨大损害。
I could test the Lambda function as a unit. But what's more important to me is they are attached to the correct APIs. There's currently no way I see that allows me to test this easily.
如果您正在考虑多个授权者，测试是否连接了正确的授权者的一种方法是让每个授权者将指纹向下传递到端点。然后您可以 ping 您的端点并让它们 return 健康检查状态。
例如，
[ HTTP Request ] -> [ API Gateway ] -> [ Authorizer 1 ] -> [ Lambda 1 ] -> [ HTTP Response ]
Payload: Payload:
user identity status: ok
authorizer: 1 authorizer: 1
在实践中，我的团队每个服务有一个授权者，这使得测试此配置变得非关键（我们只需要确保应该受到保护的端点）。
Another problem is. looking at the code, I can no longer tell what authorization is required easily... I have to look through which authorizer is supposed to be attached (eg. CloudFormation) then the Lambda code itself.
是的，这是真的，并且难以在本地测试的高度分离环境的性质是我的团队在使用 AWS 基础设施时遇到的最大问题之一。但是，我认为在处理 AWS space 时，这主要是一个学习曲线。整个开发社区对 AWS 公开的许多概念（例如基础设施即代码或微服务）仍然相对较新，因此与传统的单体开发相比，我们在这方面 space 缺乏工具和教育。
这是适合您应用的解决方案吗？如果没有深入分析，我无法告诉你。更广泛的社区中有很多意见都是双向的，但我想向您指出这篇文章，尤其是列出的谬论：Microservices – Please, don’t。使用微服务是因为您已经为它们开发了可靠的用例，而不仅仅是因为它们是计算机科学中的最新流行语。
Is there a good thing from using Authorizers? Or what's the best practice with this actually?
我的团队使用 AuthN 的授权方（通过自定义身份验证服务），并在单独的 Lambda 层处理 AuthZ（通过不同的自定义身份验证服务）。这对我们的架构非常有益，因为它允许我们将通常极其复杂的特定于对象的安全规则与简单的身份问题隔离开来。您的用例可能有所不同，我当然不会声称知道最佳实践。但是，我会向您指出 API Gateway Authorizer examples 以获得有关如何将此服务集成到您的应用程序中的更多想法。
祝你好运。
我正在使用 Cognito、API 网关和授权器。授权者被配置为缓存 5 分钟以提高性能。我觉得这是一个很好的功能。
我知道授权器是将授权逻辑保存在一个地方的好方法，应用程序可以假定用户已经获得授权。但是，我有疑问。
渗透测试报告建议，一旦登出，令牌就不能再使用了。所以这意味着为了安全，我不应该启用授权缓存？这也意味着所有经过身份验证的 API 都将通过 lambda 授权方的一次开销......
同样从编码的角度来看，使用难以端到端测试的授权器真的是个好主意吗？我可以将 lambda 函数作为一个单元进行测试。但对我来说更重要的是它们附加到正确的 APIs。目前我看不出有什么方法可以让我轻松地进行测试。
另一个问题是查看代码，我无法再轻松判断需要什么授权...我必须查看应该附加的授权方（例如 CloudFormation），然后是 lambda 代码本身。
使用授权器有好处吗？或者实际上最好的做法是什么？
For security, I should not enable authorizer caching
如果您有严格的安全要求（例如，一旦令牌失效，所有请求都应该失败），您将需要关闭授权缓存。从 https://forums.aws.amazon.com/thread.jspa?messageID=703917 看到这个答案：
Currently there is only one TTL for the authorizer cache, so in the scenario you presented API Gateway will continue to return the same cached policy (generating a 200) for the cache TTL regardless of whether the token may be expired or not. You can tune your cache TTL down to level you feel comfortable with, but this is set at level of the authorizer, not on a per token basis.
We are already considering updates to the custom authorizer features and will definitely consider your feedback and use case as we iterate on the feature.
It also means all authenticated APIs will have a go through one overhead of a Lambda authorizer...
确实如此。然而，在实践中，我的团队在 Lambda 冷启动和 ENI 附件方面比其他任何性能方面都更加努力，因此我们的授权者增加的开销最终可以忽略不计。这并不意味着性能损失不可衡量，但与将授权代码直接放在 Lambda 中相比，它最终增加了毫秒级的延迟，这种权衡在我们的应用程序中是有意义的。与之形成鲜明对比的是，Lambda 冷启动通常需要长达 30 秒。
Also from a coding perspective, is it really a good idea to use authorizers which are hard to test end to end?
在许多基于面向服务的架构构建的应用程序中，您将拥有跨多个代码库的“端到端”场景，并且只能在已部署的环境中进行测试。此级别的测试显然很昂贵，因此您应该避免测试可能被较低级别（单元、集成等）测试覆盖的功能。然而，测试您的应用程序的内聚性仍然非常重要，您需要此类测试的事实并不一定是对 SOA 的巨大损害。
I could test the Lambda function as a unit. But what's more important to me is they are attached to the correct APIs. There's currently no way I see that allows me to test this easily.
如果您正在考虑多个授权者，测试是否连接了正确的授权者的一种方法是让每个授权者将指纹向下传递到端点。然后您可以 ping 您的端点并让它们 return 健康检查状态。
例如，
[ HTTP Request ] -> [ API Gateway ] -> [ Authorizer 1 ] -> [ Lambda 1 ] -> [ HTTP Response ]
Payload: Payload:
user identity status: ok
authorizer: 1 authorizer: 1
在实践中，我的团队每个服务有一个授权者，这使得测试此配置变得非关键（我们只需要确保应该受到保护的端点）。
Another problem is. looking at the code, I can no longer tell what authorization is required easily... I have to look through which authorizer is supposed to be attached (eg. CloudFormation) then the Lambda code itself.
是的，这是真的，并且难以在本地测试的高度分离环境的性质是我的团队在使用 AWS 基础设施时遇到的最大问题之一。但是，我认为在处理 AWS space 时，这主要是一个学习曲线。整个开发社区对 AWS 公开的许多概念（例如基础设施即代码或微服务）仍然相对较新，因此与传统的单体开发相比，我们在这方面 space 缺乏工具和教育。
这是适合您应用的解决方案吗？如果没有深入分析，我无法告诉你。更广泛的社区中有很多意见都是双向的，但我想向您指出这篇文章，尤其是列出的谬论：Microservices – Please, don’t。使用微服务是因为您已经为它们开发了可靠的用例，而不仅仅是因为它们是计算机科学中的最新流行语。
Is there a good thing from using Authorizers? Or what's the best practice with this actually?
我的团队使用 AuthN 的授权方（通过自定义身份验证服务），并在单独的 Lambda 层处理 AuthZ（通过不同的自定义身份验证服务）。这对我们的架构非常有益，因为它允许我们将通常极其复杂的特定于对象的安全规则与简单的身份问题隔离开来。您的用例可能有所不同，我当然不会声称知道最佳实践。但是，我会向您指出 API Gateway Authorizer examples 以获得有关如何将此服务集成到您的应用程序中的更多想法。
祝你好运。