我应该使用AWS Cognito“username”或“sub”（uid）存储在数据库中吗？

Question

我在AWS Cognito服务中有一个经过身份验证的用户，并希望将其唯一标识符存储在数据库中。我应该存储用户的用户名（这是他的电话号码）还是他的“子”（这是他的uid）？所有Amazon API函数（如AdminGetUser）都使用“username”参数，但不使用sub / uid。

但我也读到article并且作者说“总是生成'sub'声明的价值政策而不是'username'，因为用户名是可重新分配的.Sub是UUID，用户永远不会被重新分配给另一个用户。“

所以，现在我犹豫了我必须用作唯一用户标识符 - “username”或“sub”

谢谢。

Answer 1

您应该使用sub属性。事实上，如果用户名为Erico的用户删除了他的帐户，则新用户可以稍后使用此相同的用户名，而您的映射将会出错...

  

注册用户始终需要用户名，并且在创建用户后无法更改用户名。

然而

  

用户名必须在用户池中唯一。用户名可以重复使用，但只有在用户名被删除后才会被使用。

更新

您可以在数据库中使用sub作为ID和username as属性。这样，您就可以通过username AdminGetUser获取用户。

如果您确实需要username作为数据库中的ID，则可以在删除其帐户时从数据库中删除该用户，也可以使用＆＃34; Pre Sign-up＆＃34;触发以防止用户使用数据库中已有的username。

Answer 2

参考 username.

• sub：全局唯一标识符，由 aws 设置
• subject：用户标识符，由您设置

您想要一个全局唯一标识符，但您想自己设置。

为什么不引用 sub？

sub 无法从备份中恢复。

在撰写本文时，Cognito 没有本地备份解决方案。如果您误删，您必须有自己的备份数据。由于 sub 不是可设置的字段，因此您的用户身份将不再与其以前的任意 sub 值相关联。

为什么将 subject 设置为全局唯一标识符？

全局唯一标识符是一种很好的做法。在安全上下文中使用可预测或完全可设置的标识符是几种常见攻击模式的基础。请参阅 CAPEC-21: Exploitation of Trusted Identifiers 和 CAPEC-60: Reusing Session IDs。

编辑。如果您相信亚马逊的系统会保持诚实，您甚至可以使用 sub 作为您的全球唯一 username 标识符。

Answer 3

Cognito的当前限制（到此日期）之一是列出用户，如果您将sub保存在自己的数据库中以识别您的用户，稍后您会尝试恢复由于aws 不允许按子或自定义属性进行过滤，因此无法使用来自cognito的此已保存用户的信息，因此请使用username保存uuid，并使用prefered_username作为别名用于真实用户名。

在javascript AWS.CognitoIdentityServiceProvider.ListUser中，与其他人相同。

Answer 4

如果你只想存储一个，那么sub可能是你提供的原因。

这在很大程度上取决于您的使用案例，但如果您需要使用此数据库来调用API，例如，您可以跟踪两者/两者之间的映射是一个完全有效的解决方案。