我无法通过AWS PaaS（gateway / lambda）API看到基于声明或基于角色的授权的良好设计 . 现在，无论你如何组合以下内容，似乎都有一个功能盲点：
-
网关认知用户池或自定义授权者
用于Web和用户池标识联合的 -
cognito标识池
-
网关执行授权的IAM角色
具体来说，盲点似乎是基于用户属性将认知身份与角色（发电机和s3中的键和后缀更多不同）相关联，其方式为：
-
不需要API中的自定义 endpoints 来销售IAM临时信用（因此使用除提供和/或生成的SDK之外的其他内容）
-
在每个lambda函数中都不需要授权逻辑
-
不需要在dynamo，cognito sync等中持久保存上述映射
-
不对单独的流进行分层或排序以进行授权（例如，单独的令牌）
-
允许您的用户使用外部idps登录
我认为以下是不可能或过于hacky：
-
cognito用户池，用于在池之间重叠或移动用户以表示其角色的配置
-
直接从congito身份池标识令牌获取cognito用户池属性（GetOpenIdToken）
-
有一个易于修改的客户端选择自己的权限（例如选择一个IAM角色）
-
在自定义授权程序或其他影子实现IAM中以干运行方式运行每个请求
-
实际上保护特定于角色的IAM角色具有某种共享秘密等 .
以下是一些示例及其缺点：
-
用户使用用户池凭据登录并尝试执行网关api方法 .
-
关于网关api方法的认知授权者会让我说认证 - 因此授权并将属性/声明映射到集成请求中，仍然将其留给lambda函数来实现实际的授权逻辑 .
-
自定义授权程序不会自动验证和解析用户池令牌，但我仍然可以这样做并有条件地构建角色 .
-
用户使用google凭据登录，同时拥有用户池标识，并尝试执行网关api方法 .
-
认知授权人没用 .
-
自定义授权者赢了't automatically validate and parse the google+ token, but I could still do so and conditionally construct a role. Only now I' d需要手动将其映射到用户池标识 . Cognito在这里根本没有增加任何 Value - 只是一个笨拙的文档数据库作为服务 .
-
用户使用google凭据登录，同时拥有用户池标识，然后获取标识池令牌（GetOpenIdToken）并尝试执行网关api方法 .
-
认知授权人没用 .
-
自定义授权者赢得't automatically validate and parse the cognito identity token, but I could still do so and conditionally construct a role. I still need to do manual mapping because I won' t获取具有此中间令牌的用户池属性 .
-
用户使用google凭据登录，同时拥有用户池标识，然后获取临时信用（GetCredentialsForIdentity）并尝试执行网关api方法 .
-
默认授权程序无用 . 您只需通过身份验证即可获得授权 .
-
认知授权人没用 .
-
自定义授权程序无用 .
1 回答
大多数问题的最简单解决方案是在用户池中（即在auth流中使用Lambda挂钩来检查权限，可以从身份验证生成的令牌中检索属性等等），但是您要求用户可以签名目前不支持使用外部提供程序 .
从中，您可以将Cognito联合身份用于用户池和外部提供程序，但这会带来一些尴尬 . 当多个提供者可用时，在用户池中 Build 特权身份验证lambda挂钩很麻烦，并强制用户池与其他提供者一起使用 .
从那个，我会说在一些外部存储中映射权限到身份id是要走的路，使用一些具有该id的外部钩子（Lambda？）来承担角色并获得凭据，但是你提到你不想要去做 .
我同意你的目标不是绝对可能的 . 我的建议可能是与SA取得联系，看看它们是否可以帮助您设计满足您要求的复杂解决方案 .