如何将应用程序数据与Cognito用户池+Cognito身份池用户合并？

Question

如果我有一个Cognito用户池和一个Cognito身份池，又有应用程序特定的数据，那么如何将它们结合起来是最佳实践？

举个例子，假设我在DynamoDB中存储了应用程序数据，比如用户发送的短信/短信。还假设文本消息（存储在DB中）看起来像这样：

{
    "account_id": "a-uuid-for-the-account",
    "message_body": "Hello world",
    "message_subject": "Greetings!",
    "date_sent": "...",
    "message_id": "..."
}

我应该将这个加入用户池还是身份池？例如，一个单独的账户表可能有类似以下记录：

{
    "account_id": "a-uuid-for-the-account",
    "user_pool_username": "MrBloggs"
    "addresses": [ "123 Springfield Road", "Blahsville" ]
}

我可以看到加入用户池的缺点，因为你可能会引入其他IDP，这样就会失败。所以也许你应该使用身份池“identity”的ID？

最后，这个问题让我想知道存储在用户池中的'attributes'有什么意义？以邮政地址作为上面使用的例子，如果这些地址存储在用户池中，那么你必须单独为其他IDP的用户存储地址——重复努力并使软件变得复杂。

谢谢！

- pogul

Answer 1

一种选择是将Cognito用户池用作您的Cognito身份池的提供程序，然后提供给您访问Dynamo的凭据。

如果您使用多个提供商，最合理的方法可能是将Cognito身份池生成的ID（身份ID）用作Dynamo中的键，因为用户可能只使用某些公共提供商而不是用户池进行登录。

此身份ID在链接登录后保持恒定，但有一个例外。如果两个经过身份池验证的身份合并，生成的身份ID可能是任何一个。由于Dynamo的工作方式，这意味着您必须捕获合并事件，然后获取所有存在于旧密钥的Dynamo条目，删除它们，并使用新密钥重新插入它们。这显然不是最顺畅的场景，我们会将其作为功能请求，以使此用例变得更加容易。

针对用户存储数据并非针对Cognito联合身份（身份池）而设计，只适用于用户池。当用户池更多地是一个独立实体时，而不是在您所描述的用例中使用时，它确实是最有意义的。

- Jeff Bailey

---

Cognito身份池生成的ID（身份ID）是否可以用作DynamoDB表中的主键？这是推荐的行为吗？ - Dominique Vial

身份验证标识的唯一更改时间是在身份合并的情况下。如果身份a具有用户池身份验证，而身份b具有Facebook身份验证，那么您给予身份a的用户池令牌和身份b的Facebook令牌与身份a合并时，就会触发合并操作。结果可能是a或b的身份标识，这是随机的。 - Jeff Bailey

所以，如果您可能合并，它可能会改变，否则不会。如果您正在使用用户池，则子字段是该用户的唯一标识符，也可以使用。 - Jeff Bailey