API网关授权器和注销(性能/安全考虑)

为了安全起见,我不应该启用授权缓存

如果您有严格的安全要求(例如,一旦令牌失效,所有请求都将失败),那么 将 需要关闭授权缓存。请参阅以下答案: 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 . 使用微服务是因为您已经为它们开发了一个可靠的用例,而不一定仅仅因为它们是计算机科学中最新的流行词。

使用授权人有什么好处吗?或者这是什么最佳实践呢?

我的团队使用authorizers进行authn(通过自定义auth服务),并在单个lambda层处理authz(通过不同的自定义auth服务)。这对我们的体系结构非常有益,因为它允许我们从简单的身份问题中分离出通常极其复杂的特定于对象的安全规则。您的用例可能不同,我当然不会声称了解最佳实践。不过,我会指给你看 API Gateway Authorizer examples 有关如何将此服务集成到应用程序中的更多想法。

祝你好运。