C# 实现非内存Identity Server存储—如果SubjectId是数据库表的实际Id，可以吗？

与一个较大的唯一数字（默认情况下为主键）相比，如果我只是将主键列存储在其中，这是否非常糟糕？对于某些用户，该值将是

1

，对于其他用户，该值将是

9480

，但它几乎不会像默认的subjectId那样大。它是一个自动标识列，因此您可以想象它的行为方式

如果这是一种不好的做法，请解释原因，因为我看不出用这些属性填充其他列的原因。令牌应受到签名的保护，因此他们不能以任何方式滥用此令牌？

来自：

主题标识符是本地唯一的，从不重新分配 发卡机构中最终用户的标识符，用于 由客户端使用

因此，用户的Id非常合适，这也是

sub

的默认值。并且您可以自由了解如何实现Id（例如Guid或int）。但规范中还有更多内容：

本规范定义了两种主题标识符类型：

公开的

这为所有客户端提供相同的子（主题）值。如果提供程序没有subject\u types\u支持的元素，则为默认值 在其发现文件中

成对的

这为每个客户机提供了一个不同的子值，从而使客户机不必在没有关联的情况下关联最终用户的活动 允许

默认情况下，IdentityServer使用

public

subs。如果您关心隐私，您可以切换到

pairwise

subs

---

但是，目前IdentityServer不支持特定于客户端的主题。这似乎是为将来的版本而设计的，因为。

主键是为索引而制作的。主键是唯一的数字。主键在分配后将被设置为静态。如果您需要一个ideinitifier、索引、复选框标识符或类似的东西，那么使用现有PK是最好的选择。我对它们对public的定义感到有点困惑：“这为所有客户端提供了相同的子（主题）值。”-它们是什么意思？主客体总是不同的，或者客户是指最终用户？每个用户都有自己的主体，他们从来都不一样。因为我无法理解公共的定义，我甚至无法理解帕里维的想法是什么。如果你能澄清这一点，那就太好了@这是从客户端（应用程序）的角度进行的。Public表示每个客户端都会收到此身份（用户）的相同sub。但是，使用pairwise，每个客户机都会收到一个不同的（但对于该客户机是固定的）身份的sub。这应该可以防止来自app1和app2的主机可以比较身份，并基于sub创建配置文件。啊，谢谢，现在我完全理解了！这是一件好事，但它可能会导致更多的混乱和/或不一致。想象一下，用你的谷歌账号对1系统进行身份验证——你的主体在那里是48，但你进入了另一个——那里是3003。如果这两个客户端应用想要进行协作，那么它们将很难做到这一点，因为它们没有如此明显的方式来验证这两个用户。尽管在许多其他情况下，拥有子声明本身不必是id的精确值（如果不需要两个客户端应用程序进行通信），这是一件好事，但唯一的要求是它在权限内是唯一的。因此，如果愿意，您可以对其进行哈希运算，或者将其映射到一个随机但固定的guid。使用外部提供程序可以创建本地用户。现在，您可以使用提供者的值，例如与前缀（如google_48）结合使用，而不是本地id 3003。或者使用本地id和原始值作为附加声明。