我一直在尝试在使用Api网关的无服务器Web应用程序中集成用户身份验证和授权的解决方案，并向客户公开。用户通过Cognito用户池登录并通过Cognito联合身份获取临时AWS访问密钥，然后前端客户端使用这些密钥执行对API的签名请求。我还使用角色映射将用户声明映射到IAM角色。
应用程序需要执行涉及用户的操作。例如：
它应该能够将用户分配到组。为此，有一个Dynamo表使用联合身份标识作为Hash密钥。这在能够备份联合身份数据方面成为问题，因为身份ID是自动生成的，而不是我的控制。因此，如果我丢失了标识池，即使我可以从备份恢复数据集，Dynamo表中的那些散列键最终将指向不再存在的资源，因为身份ID将被重新生成。解决这个问题的方法是在每个数据集中包含一个将手动填充的“uuid”键值对。即使联合身份在身份创建上没有触发器，因此需要一种解决方法。此外，由于无法在没有用户访问令牌的情况下找到与给定身份相关联的Cognito用户池条目，因此我无法将身份重新附加到其各自的Cognito用户。
用户应该能够创建资源，当这些资源显示在UI中时，他们应该包含其创建者的用户名。由于该数据（用户名）存储在Cognito用户池中，并且在给定身份ID的情况下无法获取它，因此我必须在我的API请求中包含用户的JWT访问令牌，其中包含他的数据和声明，以及然后每次验证和解码它。拥有这种额外的授权逻辑似乎通过临时AWS凭证超越了授权的目的。
这让我想知道我是否只是尝试将联合功能用于它不是为其设计的用例。尽管我总是觉得能够采用统一的方式来控制对所有AWS资源的访问，包括自定义无服务器端点。
我的理解是否错误，或者它是否真的是“不适合工作的工具”？