我有轻微的架构问题。 我有身份服务器解决方案，使用身份用户存储(数据库中的用户)对用户进行身份验证。我在这里有登录功能和注册功能，所以我必须在这里使用 DbContext。我有另一个解决方案 API，我在其中保存不是标识表的自定义表。所有表都位于同一数据库中。
现在，当我通过API添加新记录时，我以某种方式想要将CreadetBy 与身份用户连接起来。我知道我可以从声明中获取有关用户的信息，然后在创建新行时插入，但这是一个很好的做法吗？
另一个问题是，我是否应该将注册操作移出 IdentityServer 项目，并且仅将登录功能用于那里的身份用户存储并将注册放入 API，这样我就不会在两个地方复制 ApplicationUser 的其他字段？
据我所知，您应该保持关注的分离。切勿在不共享相同上下文的表之间建立关系。这意味着Cars永远无法链接到AspNetUsers。
它是关于对象和字段的含义。例如，IdentityUser 和 CustomUser 似乎是相等的，但它们不是。IdentityUser 具有识别用户所需的所有信息，因为 CustomUser 拥有自定义模型所需的所有信息。实际上，您可以拥有没有登录帐户的自定义用户。
还要考虑电子邮件地址。在两个上下文中都有这个字段似乎是多余的，但实际上我可以使用我的 Google 帐户登录，同时我想在我的自定义电子邮件地址上接收更新。
那么，CreatedBy 字段的含义是什么，您将如何使用它？如果它是自定义上下文的一部分(如报表)，则您应该有一个 CustomUser 表并与该表相关。如果您只是出于管理目的进行检查，则存储用户名可能就足够了。您要按该字段查询吗？您是否需要其他信息，例如自定义用户地址？
如果做得好，我认为你实际上没有多余的字段。因为它们都有不同的目的/含义。
无论如何，您都不想超出上下文进行关联。而且您不希望最终发送 id 列表以从另一个上下文中检索信息。
问题是您要链接当前用户。标识令牌用于标识用户。这对您的资源没有任何意义。但访问令牌包含有关资源中实际用户的信息。
通过将授权保持在资源附近，您可以使用自定义用户 ID 扩展授权用户。将此信息添加到访问令牌，因为它是授权的一部分。它告诉资源用户只能访问指定用户的数据。
使用 [Access token].customUserId，您可以匹配 CustomUser。因此，创建者的值应为 CustomUser.Id。
我还想推荐这篇文章：https://leastprivilege.com/2016/12/16/identity-vs-permissions/