AWS API Gateway自定义授权程序是否有用？

Question

我希望为AWS Lambda/zappa使用一些"无服务器api服务器",它使用自定义API网关授权程序进行用户身份验证.在无服务器的AWS lambda服务中,使用自定义授权器而不是直接在代码控制器中检查已发布的JWT令牌是否具有相当大的安全性或成本优势？对我来说,检查代码可能更方便.

更新我去了pre请求钩子,但是有头级别的授权器,它更容易用于CORS,但我认为zappa不支持它.也可以通过swagger上传为Options设置模拟API,如果成功则会更新.

Answer 1

我认为没有严格的安全或成本效益.好处是它是一个单一的地方,一个代码,处理您的授权.它可以防止您在API后面部署的每个Lambda函数中复制该授权代码.它允许您更新单个函数以对授权逻辑进行任何更改.

从它为您的授权逻辑提供单一事实来源的角度来看,它允许您实现关注点的分离,可以说它可以增强您的应用程序的安全性.

话虽这么说,如果你的整个API都包含一个Lambda函数,那么这个好处有点可疑.我认为当您的API具有许多Lambda函数或您的API网关位于传统HTTP服务器之前时,API网关自定义授权程序真正变得有用.

Answer 2

@Mark B 提出了很好的观点，我当然不会质疑他的回答中的任何内容。尽管如此，我还是想为这次对话做出贡献。

更具体地为您量身定制的答案可能取决于 JWT 的来源以及它们的获取、使用和刷新方式。在以下场景中使用自定义授权者可能有意义：

使用案例1

如果您想在多种不同类型的授权背后保护单个 Lambda，自定义授权方可能会很有用。例如，您可以创建三个不同的 API Gateway 终端节点，每个终端节点调用相同的 Lambda，但使用不同的授权方。这与 Mark 关于 DRY 好处的观点相关。

用例2

自定义授权者使您能够在授权者代码中内联构建 IAM 权限。您可以构建任意您喜欢的权限集，而不是将预先存在的 IAM 角色分配给调用者。请注意，如果您以某种方式使用（不受信任的）用户输入来分配 IAM 权限，这很容易成为令人讨厌的攻击媒介。

用例 3

Lambda 非常适合隐藏秘密。例如，您有一个前端 JS 应用程序，并且需要参与需要客户端 ID 和客户端密钥的 OAuth 2.0 流程。或者您需要调用需要某种 API 密钥的端点。显然，您不能将这些秘密暴露给浏览器。

这些值可以加密并存储在特定于 Lambda 函数的环境变量中。虽然您当然可以在后端 lambda 中采用这种方法，但使用授权者具有以下好处：

我喜欢能够尽可能严格地限制这些秘密的范围。通过使用授权者，我的应用程序可以幸福地不知道这些秘密。这与马克关于关注点分离的观点相关。

IAM 和最小权限

我希望我的后端代码永远不会被未经授权的各方调用。因此，我几乎在创建的每个 API 网关资源上都使用某种类型的授权者。我用过定制的授权者，但它们是我最后的手段。我大部分时间都依赖 IAM 授权，使用 Cognito 将代币交易为临时 IAM 凭证。

如果您在后端 lambda 中而不是在授权方中执行授权，则在围绕后端 lambda 定义 IAM 控件时，您就不会受到如此严格的限制。这违反了最小特权原则。这不仅仅是代码组织和应用程序架构的问题；这是一个合理的安全问题。您实际上暴露了比您需要的更多的攻击面。

此外，当您的后端增长时，IAM 的真正威力就会显现出来。您的后端 lambda 可能需要写入 S3、调用其他 Lambda、发布到 SNS 或 SQS、与 RDS 或 DynamoDB 交互等。我建议“最佳实践”规定所有这些访问都由严格的 IAM 管理政策。根据我的经验，使用 API 网关授权者（任何类型，不一定是自定义）来分配角色是实现此目的的最直接方法。