Identity Server 6新增用户关联数据表的最佳实践咨询

问题背景 #

我刚接触Identity Server和ASP.NET Core Identity，现有一个基于.NET6、使用Identity Server 6的ASP项目，采用Entity Framework处理数据库，包含Identity Core的ApplicationUser模型。我想开发一个存储用户收藏汽车及评分的API，目前有三种思路：

思路1：将新增数据放入ApplicationUser自定义字段，复用Identity数据库 #

namespace IdentityServer.Models
{
 public class ApplicationUser: IdentityUser
 {
    // Add custom fields.
    public List<Car>? Cars { get; set; }
    public List<CarRatings>? CarRatings { get; set; }
    public string? OtherData {get; set; }

  }
}

思路2：通过导航属性创建独立表，仍使用Identity数据库 #

namespace IdentityServer.Models
{
 public class ApplicationUser: IdentityUser
 {
    // Add Other Tables
    public ICollection<Cars> Cars { get; set; }     // Entity Navigation Property

 }

 public class Cars {

    public List<Car>? Cars { get; set; }
    public List<CarRatings>? CarRatings { get; set; }
    public string? OtherData {get; set; }

    // Maybe has a foreign key if navigation property isn't enough.
 }
}

思路3：为API创建独立数据库，复制UserID关联用户 #

为API创建独立数据库（如API_Car），但不清楚如何关联Identity Server/Identity Core的用户，考虑复制UserID字段到该数据库。

我曾认为用户专属数据需存在IdentityServer/Identity Core数据库中，API仅做授权校验并提供通用数据，但这样会导致强耦合，不利于后续替换IdentityServer。想咨询：与Identity Server配合的API数据库设计的行业最佳实践是什么？

最佳实践建议 #

优先选择思路3：API使用独立数据库，通过用户ID关联 #

这是行业最推荐的方案，核心原因如下：

• 解耦身份系统与业务系统：Identity Server的核心职责是身份认证、授权管理，把业务数据（如用户收藏的汽车、评分）放在独立数据库，能避免业务逻辑污染身份系统。后续替换Identity Server时，只需保证业务数据库能拿到合法的用户ID即可，改动成本极低。
• 数据库职责清晰：Identity数据库专注存储用户身份、角色、凭证等核心身份数据，业务数据库专注处理业务逻辑，各自优化存储结构和性能，不会因业务数据膨胀影响身份认证效率。
• 扩展性更强：如果后续业务拆分（比如把汽车评分模块做成微服务），独立数据库的架构更容易拆分，不会和Identity数据库绑定。

关联用户的具体实现 #

• 用Identity用户ID作为业务数据库外键：在业务实体（如UserCarFavorite、CarRating）中添加UserId字段（类型与IdentityUser.Id一致，通常为string），无需复制用户其他信息到业务数据库。
• 从JWT Token解析用户ID：API处理请求时，从授权的JWT Token中解析sub（Subject）字段，这个值就是Identity Server颁发的用户唯一标识，直接作为业务数据的关联ID即可。除非业务需要用户其他身份属性，否则无需调用Identity Server接口获取用户信息。

为什么不推荐前两种思路 #

• 思路1：把业务集合直接放在ApplicationUser中，会导致用户表数据急剧膨胀，查询用户信息时附带大量业务数据，严重影响Identity系统性能；EF Core处理大集合字段的效率远不如独立表，后续业务迭代也会受限。
• 思路2：虽然用了独立表，但仍和Identity数据库绑定，会导致Identity数据库臃肿、职责不清晰。后续Identity Server升级或迁移时，业务表结构会成为阻碍；同时业务逻辑变更可能影响Identity的DbContext，增加维护风险。

额外注意点 #

• 保证用户ID一致性：确保API解析的sub值与Identity数据库中的用户ID完全一致，不要自行修改用户ID生成规则。
• 无需同步用户数据：除非业务必须展示用户昵称、头像等信息，否则无需复制用户身份数据到业务数据库。如果需要这些信息，可以通过Identity Server的UserInfo接口获取，或者在JWT Token中添加自定义声明（如name、picture），API直接从Token读取即可。

内容的提问来源于stack exchange，提问作者Scottish Smile