多个社交提供商的 AWS Cognito 联合身份：合并身份或将它们分开更好？

Question

通过在 Cognito 调用中传递两个登录名，可以将多个 AWS Cognito 联合身份（例如，同一电子邮件的 Facebook 和 Google 登录名）合并为一个身份。但是知道我可以合并身份并不能回答我是否应该合并身份。

合并身份与保持身份分开的利弊是什么？（我们将用户配置文件存储在我们自己的数据库中；我们不使用 Cognito 用户池。如果我们不合并身份，那么我们的后端数据库将在我们的后端存储每个身份 ID 到正确用户 ID 的映射-结束数据库。）

这是当同一用户尝试同时使用 Facebook 和 Google 进行身份验证时应用程序的当前工作流程：

1. 在客户端（它是一个 Web 应用程序）上，新用户单击登录并选择使用 Facebook 登录。
2. 客户端代码将用户登录到 Cognito Federated Identities 并获取新的联合身份 ID，该 ID 被授权调用我们的 AWS Lambda 函数。
3. 客户端调用我们的getOrCreateUserProfileLambda 函数，该函数使用 Cognito 身份 ID 作为密钥来查看该 Cognito 身份是否已与用户关联。
4. 因为在我们的数据库中没有找到具有此身份 ID 的其他用户，并且因为没有其他用户拥有此电子邮件地址（因为它是一个全新的用户），所以我们的 Lambda 函数将在我们的数据库中创建一个新的用户配置文件并返回该配置文件返回给用户。
5. 稍后，用户尝试使用 Google 登录（在同一台设备或另一台设备上）。
6. 为此 Google 身份创建了一个新的联合身份。
7. 我们的getOrCreateUserProfileLambda 函数找不到匹配此身份 ID 的现有用户，但确实找到了具有相同电子邮件地址的另一个用户。

此时我们有三个选择：

• A) 向用户返回错误信息，例如“请使用您的 Facebook 帐户登录”。这是我们想要改变的当前行为。
• B) 通过要求用户也使用 Facebook 登录来合并身份，然后将两个身份传递给 Cognito，Cognito 将合并它们。见/sf/answers/3153158641/
• C) 在我们的后端数据库中添加一个映射行以将新身份映射到用户现有的用户配置文件。现在该用户将拥有两个联合身份：一个使用 Facebook 提供程序，一个使用 Google 提供程序。

选项 (B) 与选项 (C) 的优缺点是什么？以下是此比较的起点。我缺少什么优点/缺点？

合并身份

• 亲
  • 更简单/更快的查找，因为每个用户只有一个身份 ID 必须在后端编入索引
  • 我认为这是最安全的解决方案？
• 骗局
  • 合并过程本身似乎很复杂且容易出错。例如，合并后，如果新 ID“赢得”合并，那么我们需要用用户配置文件中的新 ID 替换旧 ID……如果在此过程中出现问题，我们可能会留在一种不可恢复的状态，其中 Cognito 只知道新的（合并的）ID，但我们的数据库只知道旧的。
  • 更复杂的用户体验，用户必须在同一会话中同时登录 Facebook 和 Google 帐户（尽管只登录一次）才能链接这些帐户。
  • 以后对链接的任何更改都必须通过 Cognito API

保持分开

• 亲
  • 更简单的用户体验：我们可以通过匹配电子邮件地址来链接社交帐户；无需在一个会话中同时登录
  • 可以仅在我们的后端数据库内控制链接，这应该可以更轻松地构建添加/删除/更改身份->用户配置文件链接的管理工具，而不是必须调用 Cognito 的 API 来执行这些操作。
  • 没有 Cognito 与我们的后端数据库不同步的风险。如果链接失败，用户可以简单地重试。
• 骗局
  • 需要一个 many:1 索引来映射 Identity ID -> User Profile，而不是单个索引列
  • 这是一个不太安全的解决方案吗？如果是这样，为什么？
  • 这在 AWS 费用中是否更昂贵？如果是这样，为什么？

我倾向于“保持独立”解决方案，因为它看起来更容易实现（没有额外的用户体验工作流程）并且对用户来说更容易（出于同样的原因：没有新的用户体验工作流程）。这是一个错误吗？

Answer 1

很难给你一个答案，我认为你已经提供了所有可能解决方案的主要优点和缺点。

我只会尝试澄清其中的一些问题，我认为这是选择一种解决方案而不是另一种解决方案的关键。

首先，表明我也更喜欢保持单独的解决方案。让我尝试解释一下原因。

从用户体验的角度来看，很明显，保持独立的解决方案对用户来说是更好的方法。要合并不同社交提供商的身份，用户需要在更复杂的应用程序注册工作流程中使用它们登录。但这个过程只是出于技术决策的动机，不会给用户带来任何实际的好处。

我认为更好、更简单的解决方案是仅包含每个身份和关联电子邮件之间的映射，如您在保持单独解决方案中建议的那样，并让用户通过他或她喜欢的提供商透明地登录到应用程序“合并”，在您的应用程序代码中，所有这些登录机制。无论您使用哪种类型的底层信息系统来存储用户信息，都可以轻松实现此要求。

请还考虑一下，如果您需要在应用程序中包含另一个不同的社交提供商，并且现有用户想要使用该新提供商登录您的应用程序，会发生什么：身份将如何合并？用户是否应该再次重复该过程？

In addition, the identity merge functionality is something very specific to Cognito. If you adopt the merge solution, you are taking the risk of tightly coupling your application with AWS and AWS Cognito. If you need to move your application to another cloud provider or on-premises deployment, you maybe won't have the ability to make such an association. Again, the mapping between some kind of identity information and your internal user model adopted in the keep separate solution seems like a much better and portable approach.

The risk of not being in sync with Cognito could be another great problem. What will be the recover mechanism?

The only real downside to the keep separate solution might be that you will likely incur more charges from AWS. As you can see in the product pricing documentation, AWS will charge you for every monthly active user (MAUs). If you have more identities, as with the keep separate solution, it is probably that there will be more MAUs and you may incur higher costs. In any case, these costs will not be much higher and, nevertheless, I believe that the advantages that the keep separate solution offers will compensate this minimum price increase.

Finally, I don't think the keep separate solution is a less secure option: although it seems you are federating identities to allow your users to interact with AWS services, the same policy and role assumption will apply regardless of the actual identity the user provides.

我认为合并解决方案最适合以下场景：您具有联合身份并且需要唯一标识用户，无论他们如何进行身份验证，但可能会强制执行与基于 AWS 资源的使用相关的某种策略（自定义角色假设等）仅针对那些特定身份，并且可能在您没有可用的应用程序后端时。

无论最终采用哪种解决方案，一个关键的成功因素是维护用户模型和相关逻辑，尽可能独立于用于验证用户身份的机制：保持分离的解决方案也有助于以这种方式思考。