适用于多个社交服务提供商的AWS Cognito联合身份：更好地合并身份或将其分开？

问题描述

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

合并身份与将身份分开要有什么利弊？ （我们将用户个人资料存储在我们自己的数据库中；我们不使用Cognito用户池。如果我们不合并身份，则后端数据库会将每个身份ID映射到正确的用户ID的映射结束数据库。）

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

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

目前，我们有三个选择：

• A）向用户返回错误，例如“请使用您的Facebook帐户登录”。这是我们要更改的当前行为。
• B）通过要求用户也使用Facebook登录来合并身份，然后将这两个身份传递给Cognito，后者将对其进行合并。参见https://stackoverflow.com/a/45045123/126352
• C）在我们的后端数据库中添加一个映射行，以将新标识映射到用户的现有用户配置文件。现在，该用户将具有两个联合身份：一个使用Facebook提供程序，一个使用Google提供程序。

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

合并身份

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

保持独立

• 专业版
  • 简单的用户体验：我们可以通过匹配电子邮件地址来链接社交帐户；一次会话无需两次登录
  • 可以仅在我们的后端数据库中控制链接，这将使构建添加/删除/更改身份->用户配置文件链接的管理工具更加容易，而不必调用Cognito的API来执行这些操作。 / li>
  • 没有Cognito与我们的后端数据库不同步的风险。如果链接失败，则用户只需重试即可。
• 骗局
  • 需要很多：1索引来映射身份ID->用户个人资料，而不是单个索引列
  • 这是不太安全的解决方案吗？如果是这样，为什么？
  • AWS收费是否更昂贵？如果是这样，为什么？

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

解决方法

给您一个答案非常困难，我想您已经提供了所有可能解决方案的主要利弊。

我只会尝试澄清其中一些，我认为选择一个解决方案而不是其他解决方案的关键。

首先，请指出我也希望保留单独的解决方案。让我尝试解释原因。

从UX的角度来看，对于用户而言，保持独立的解决方案显然是一种更好的方法。为了合并不同社交提供者的身份，用户需要在更复杂的应用程序注册工作流程中与他们登录。但是，此过程仅出于技术决定的目的，不会为用户带来任何实际利益。

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

还请考虑如果您需要在应用程序中包含其他社交提供程序，并且已经存在的用户想要使用该新提供程序登录到您的应用程序中，将会发生什么情况：如何合并身份？用户是否应该再次重复该过程？

此外，身份合并功能是Cognito非常特定的功能。如果采用合并解决方案，则会冒将应用程序与AWS和AWS Cognito紧密耦合的风险。如果您需要将应用程序移至其他云提供商或本地部署，则可能无法建立这种关联。同样，在保持独立的解决方案中采用的某种身份信息与您的内部用户模型之间的映射似乎是一种更好且可移植的方法。

与Cognito不同步的风险可能是另一个大问题。什么是恢复机制？

采用单独解决方案的唯一真正缺点可能是您可能会从AWS收取更多费用。正如您在product pricing documentation中看到的那样，AWS将向您收取每个月活跃用户（MAU）的费用。如果您拥有更多身份，如使用单独解决方案，则可能会有更多的MAU，并且您可能需要支付更高的费用。无论如何，这些成本都不会高得多，不过，我相信，采用单独解决方案所提供的优势将弥补这一最低价格的上涨。

最后，我认为保持独立的解决方案不是一个不太安全的选择：尽管似乎您正在联合身份以允许您的用户与AWS服务进行交互，但是无论实际身份如何，都将应用相同的策略和角色假设用户提供。

我认为合并解决方案将最适合您具有联盟身份并且需要唯一标识用户而不管他们如何进行身份验证的方案，但是可能会强制实施与使用相关的某种策略（自定义角色假设等） AWS资源仅基于这些特定身份，并且可能在您没有应用程序后端可用时。

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

,

从用户的角度来看，通过第二个提供程序登录时发现自己没有以前的内容，这会让您感到困惑和不安。从这个角度来看，我认为合并将是最好的最终目标。

现在，从技术角度来看，我对此有所摇摆，发现这很麻烦。当用户首先使用电子邮件登录，然后使用社交登录时，我设法将身份合并。我猜唯一的选择是拥有一个预注册lambda触发器，该触发器可以检查数据库中是否有该特定电子邮件的先前登录信息，并要求用户也登录以进行合并或仅继续在现有电子邮件上登录。这比说要存在一个以上的登录名要容易得多。

关于谁“赢得”合并的问题，它始终是现有的合并。最后，这也没关系，因为所有登录名将通过调用使用相同的认知联合ID。