amazon-web-services - 多个社交提供商的 AWS Cognito 联合身份 : better to merge identities or keep them separate?

Question

通过在 Cognito 调用中传递两个登录名，可以将多个 AWS Cognito 联合身份(例如，同一电子邮件的 Facebook 和 Google 登录名)合并为一个身份。但是知道我可以合并身份并不能回答我是否应该合并身份。
合并身份与保持身份分开的利弊是什么？ (我们将用户配置文件存储在我们自己的数据库中；我们不使用 Cognito 用户池。如果我们不合并身份，那么我们的后端数据库将在我们的后端存储每个身份 ID 到正确用户 ID 的映射-结束数据库。)
这是当同一用户尝试同时使用 Facebook 和 Google 进行身份验证时应用程序的当前工作流程:

在客户端(它是一个 Web 应用程序)上，新用户单击登录并选择使用 Facebook 登录。

客户端代码将用户登录到 Cognito Federated Identities 并获取新的联合身份 ID，该 ID 被授权调用我们的 AWS Lambda 函数。

客户调用我们getOrCreateUserProfile Lambda 函数使用 Cognito 身份 ID 作为 key 来查看该 Cognito 身份是否已与用户关联。

因为在我们的数据库中没有找到具有此身份 ID 的其他用户，并且因为没有其他用户拥有此电子邮件地址(因为它是一个全新的用户)，所以我们的 Lambda 函数将在我们的数据库中创建一个新的用户配置文件并返回该配置文件返回给用户。

稍后，用户尝试使用 Google 登录(在同一台设备或另一台设备上)。

为此 Google 身份创建了一个新的联合身份。

我们的 getOrCreateUserProfile Lambda 函数找不到与此身份 ID 匹配的现有用户，但会找到具有相同电子邮件地址的另一个用户。

此时我们有三个选择:

A) 向用户返回错误，例如“请使用您的 Facebook 帐户登录”。这是我们想要改变的当前行为。

B) 通过要求用户也使用 Facebook 登录来合并身份，然后将两个身份传递给 Cognito，Cognito 将合并它们。见 https://stackoverflow.com/a/45045123/126352

C) 在我们的后端数据库中添加一个映射行以将新身份映射到用户现有的用户配置文件。现在该用户将拥有两个联合身份:一个使用 Facebook 提供程序，一个使用 Google 提供程序。

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

亲

更简单/更快的查找，因为每个用户只有一个身份 ID 必须在后端编制索引

我认为这是最安全的解决方案？

骗局

合并过程本身似乎很复杂且容易出错。例如，合并后，如果新 ID“赢得”合并，那么我们需要用用户配置文件中的新 ID 替换旧 ID……如果在此过程中出现问题，我们可能会留在一种不可恢复的状态，其中 Cognito 只知道新的(合并的)ID，但我们的数据库只知道旧的。

更复杂的用户体验，用户必须在同一 session 中同时登录(尽管只有一次)Facebook 和 Google 帐户才能链接这些帐户。

以后对链接的任何更改都必须通过 Cognito API

保持分开

亲

更简单的用户体验:我们可以通过匹配电子邮件地址来链接社交帐户；无需在一个 session 中同时登录

可以仅在我们的后端数据库内控制链接，这应该可以更轻松地构建添加/删除/更改身份->用户配置文件链接的管理工具，而不是必须调用 Cognito 的 API 来执行这些操作。

没有 Cognito 与我们的后端数据库不同步的风险。如果链接失败，用户可以简单地重试。

骗局

需要一个 many:1 索引来映射身份 ID -> 用户配置文件，而不是单个索引列

这是一个不太安全的解决方案吗？如果是这样，为什么？

这在 AWS 费用中是否更昂贵？如果是这样，为什么？

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

Answer 1

很难给你一个答案，我想你已经提供了所有可能解决方案的主要优缺点。
我只会尝试澄清其中的一些，我认为这是选择一种解决方案而不是另一种解决方案的关键。
首先，表明我也更喜欢保持单独的解决方案。让我试着解释一下原因。
从用户体验的角度来看，很明显，保持独立的解决方案对用户来说是一种更好的方法。为了合并不同社交提供商的身份，用户需要在更复杂的应用程序注册工作流程中使用他们登录。但是这个过程只是出于技术决策的动机，它不会为用户提供任何实际利益。
我认为一个更好和更简单的解决方案是只包含每个身份和相关电子邮件之间的映射，正如您在保持单独的解决方案中提出的那样，并让用户使用他或她喜欢的提供者透明地登录到应用程序“合并”，在您的应用程序代码中，所有这些登录机制。无论您用于存储用户信息的底层信息系统是什么类型，都可以轻松实现此要求。
还请考虑一下，如果您需要在您的应用程序中包含另一个不同的社交提供商，并且已经存在的用户想要使用该新提供商登录您的应用程序，将会发生什么情况:如何合并身份？用户是否应该再次重复该过程？
此外，身份合并功能是 Cognito 特有的功能。如果您采用合并解决方案，您将面临将应用程序与 AWS 和 AWS Cognito 紧密耦合的风险。如果您需要将您的应用程序移动到另一个云提供商或本地部署，您可能无法进行这样的关联。同样，某种身份信息与在保持独立的解决方案中采用的内部用户模型之间的映射似乎是一种更好且可移植的方法。
与 Cognito 不同步的风险可能是另一个大问题。恢复机制是什么？
保持独立解决方案的唯一真正缺点可能是您可能会从 AWS 产生更多费用。正如您在 product pricing documentation 中看到的那样，AWS 将针对每个月活跃用户 (MAU) 向您收费。如果你有更多的身份，就像保持独立的解决方案一样，可能会有更多的 MAU，你可能会产生更高的成本。在任何情况下，这些成本都不会高很多，不过，我相信保持独立解决方案提供的优势将弥补这种最低价格上涨。
最后，我不认为保留单独的解决方案是一个不太安全的选择:虽然您似乎正在联合身份以允许您的用户与 AWS 服务交互，但无论用户提供的实际身份如何，相同的策略和角色假设都将适用.
我认为合并解决方案最适合您拥有联合身份并且需要唯一标识用户而不管他们如何进行身份验证的场景，但可能会强制执行与使用基于 AWS 资源相关的某种策略(自定义角色假设等)仅在这些特定身份上，并且可能在您没有可用的应用程序后端时。
无论最终采用哪种解决方案，一个关键的成功因素将是保持用户模型和相关逻辑尽可能独立于用于验证用户的机制:保持独立的解决方案也有助于以这种方式思考。