多租户场景下URI与JWT的tenantId集中校验最佳方案

这是你当前技术栈下实现集中租户校验的最优选择，原因如下：

• 所有请求到达后端业务Lambda前必然先经过API网关，你可以直接为所有匹配/tenants/*前缀的路由统一绑定带租户校验逻辑的自定义授权方，完全不需要业务Lambda层面做任何改造。
• 实现逻辑极简：
  1. 授权方首先完成常规的Cognito JWT验签、过期校验，从JWT的自定义Claims中提取tenantId字段
  2. 从API网关传给授权方的事件对象event.pathParameters中直接读取路径上的tenantId参数
  3. 直接完成两者匹配校验，不一致直接返回403拒绝访问；校验通过后还可以把已经核验过的tenantId放到授权上下文里传递给后端Lambda，连业务代码的参数解析步骤都可以省去。
• 额外收益：
  不需要租户校验的端点可以单独绑定普通的JWT授权方，规则配置灵活，后续租户校验逻辑调整只需要修改授权方代码，不需要批量发布所有业务端点。

你也可以选择以下方案，但都存在明显缺陷，不建议使用：

• Lambda公共层封装：仍然需要所有业务Lambda引入公共依赖、主动调用校验方法，容易出现遗漏，规则调整后需要重新发布所有依赖的Lambda，维护成本很高。
• Cognito侧实现：Cognito仅负责身份认证，无法获取请求路径的参数，根本无法完成路径tenantId和TokentenantId的匹配校验。
• API网关请求映射模板校验：仅能实现非常简单的逻辑，自定义错误返回、复杂匹配规则都很难实现，后续维护难度极大。

内容的提问来源于stack exchange，提问作者systemdebt