能否结合REST API Gateway、Resource Policy与Lambda Authorizer实现用户与系统双认证？

我已配置了通过Lambda Integration提供服务的REST API Gateway，该API由AWS Lambda Authorizer保障安全——通过验证请求头中的JWT令牌有效性，仅允许持有有效JWT的注册用户调用。但除了用户→API的通信外，我们还需支持系统→API的通信，且该通信不应依赖“系统用户”。

目前我已将API Gateway的所有资源配置为使用Lambda Authorizer作为授权方式，满足了用户→API的通信流程。

对于系统→API的通信，我计划通过IAM Roles实现：让系统承担AWS角色，使用AWS SigV4对HTTP请求签名，进而通过REST API Gateway Resource Policy基于AWS策略（验证特定角色为主体）允许或拒绝系统访问API，但这需要绕开该场景下的Lambda授权。

AWS文档对此混合场景的说明不够清晰：似乎要通过Resource Policy实现IAM Roles授权，需将API Gateway资源配置改为使用AWS_IAM作为授权方式而非LAMBDA。尽管文档提到可结合API Resource Policies与Lambda Authorizer，但仅适用于阻止非特定VPC或IP范围的请求。

我的目标是实现如下流程：

User's requests  --(JWT)--> Lambda Authorizer ---|
(Identity via Oauth)                             |
                                                 |-> API Gateway
System's requests --(SigV4)--> Resource Policy --|
(Identity via IAM Role)

但我未找到为两种独立场景分别配置专属授权流程的方法，发现每个API Gateway资源端点仅能设置一种授权方式。

请问是否可通过REST API Gateways实现该目标？若不能，有哪些替代方案？

可以通过REST API Gateway实现该目标，以下是几种可行方案： #

方案1：扩展Lambda Authorizer兼容双场景验证

既然每个端点只能配置一种授权方式，最直接的方式是让现有Lambda Authorizer同时处理两种身份验证逻辑：

• 针对用户请求：检查请求头中的JWT令牌，验证有效性后返回允许访问的IAM策略
• 针对系统请求：识别请求的SigV4签名标识（可通过event.requestContext.identity.authenticationType字段判断是否为AWS_IAM类型），调用STS的GetCallerIdentity接口验证发起请求的IAM角色是否在预设的允许列表中，符合条件则返回允许访问的策略

这种方案无需修改API Gateway的授权配置，仅需扩展Lambda Authorizer的逻辑，实现成本较低且逻辑集中。

方案2：为系统请求创建独立资源路径

如果希望完全隔离两种授权逻辑，可以为系统访问单独创建一套带前缀的API资源（比如/system/原路径），将这些资源的授权方式设置为AWS_IAM，同时配置Resource Policy仅允许指定的IAM角色调用。

该方案的优势是两种授权流程完全独立，互不干扰，但需要维护两套API路径，会增加一定的管理成本。

方案3：利用API Gateway请求条件路由（进阶）

可以在API Gateway中配置请求条件，根据自定义请求头（比如X-Auth-Mode: system）或参数，将请求分流到不同的授权逻辑：

• 为同一资源配置两种集成，通过请求条件判断触发Lambda Authorizer还是AWS_IAM授权
• 结合阶段变量或请求模板实现动态路由

这种方案灵活性最高，但配置复杂度也相对较高，适合对架构扩展性要求高的场景。

关键注意事项 #

• 若采用方案1，需确保Lambda Authorizer的执行角色拥有调用STSGetCallerIdentity的权限
• 无论哪种方案，Resource Policy都可作为额外安全层，但不能替代授权器的核心验证逻辑
• 系统请求使用SigV4时，需确保对应的IAM角色拥有execute-api:Invoke权限，且Resource Policy明确允许该角色访问目标API资源

内容的提问来源于stack exchange，提问作者João Pedro Schmitt