如何实现对接外部SQL数据库的UserManager与内存存储JWT认证的SignInManager

这套组合配置完全具备可行性。ASP.NET Core Identity 的组件设计本身就是基于接口解耦的，不存在必须绑定单一存储实现的硬限制，所有教程里的全量绑定逻辑只是为了简化入门流程，并非框架的强制要求。

• UserManager<TUser> 的核心依赖是IUserStore<TUser>，所有和用户基础信息读写相关的操作都会走这个接口
• SignInManager<TUser> 除了依赖UserManager，还会按功能拆分依赖独立的存储接口：用户密码校验走IUserPasswordStore、令牌读写走IUserTokenStore、双因子校验走IUserTwoFactorStore、用户确认状态走IUserConfirmationStore
• 只要在DI容器里给不同的存储接口绑定不同的实现，就能实现基础用户信息走外部SQL库、临时令牌走内存存储的组合效果，完全不需要改动框架的核心逻辑。

1. 实现对接外部SQL库的只读IUserStore #

• 不需要引入EF Core的全量迁移流程，直接基于现有SQL表结构，实现最小可用的用户存储接口即可
• 仅实现用户查询、密码哈希校验相关的读方法：包括FindByIdAsync、FindByNameAsync、GetUserIdAsync、GetPasswordHashAsync等，直接用现有SQL客户端（Dapper、原生SqlClient等）写查询逻辑就行
• 所有涉及写操作的方法（新增用户、更新用户、删除用户、修改密码哈希等），直接抛出InvalidOperationException("当前应用为只读模式，不支持对外部用户库的写操作")即可，完全符合业务规则
• 涉及令牌、双因子、用户声明相关的接口成员，不需要实现具体逻辑，同样抛出不支持类异常即可——因为这些功能会被后续注册的内存存储接管，不会走到只读Store的逻辑里

参考最简实现结构：

public class ExternalReadOnlyUserStore : IUserStore<ApplicationUser>, IUserPasswordStore<ApplicationUser>
{
    // 注入现有SQL库的查询客户端
    public async Task<ApplicationUser?> FindByNameAsync(string normalizedUserName, CancellationToken cancellationToken)
    {
        // 执行现有SQL库的用户查询逻辑
    }

    // 所有写操作直接抛异常
    public Task<IdentityResult> CreateAsync(ApplicationUser user, CancellationToken cancellationToken)
    {
        throw new InvalidOperationException("外部用户库为只读，不支持新增操作");
    }
    // 其他接口成员按需实现，写操作统一抛不支持异常
}

2. 实现内存版的令牌存储 #

• IUserTokenStore<TUser> 接口的实现面非常小，仅包含4个方法：获取令牌、设置令牌、删除指定令牌、删除用户全量令牌，基于静态ConcurrentDictionary做进程内存储即可，完全满足重启清空的业务要求

参考最简实现：

public class InMemoryUserTokenStore : IUserTokenStore<ApplicationUser>
{
    // 进程内静态字典，重启自动清空
    private readonly ConcurrentDictionary<string, string> _tokenCache = new();

    public Task SetTokenAsync(ApplicationUser user, string loginProvider, string name, string value, CancellationToken ct)
    {
        var key = $"{user.Id}:{loginProvider}:{name}";
        _tokenCache.AddOrUpdate(key, value, (k, old) => value);
        return Task.CompletedTask;
    }
    // 实现剩余3个接口方法，全部操作内存字典即可
}

3. 拆分注册DI服务，避免全量绑定 #

不要使用默认的AddEntityFrameworkStores全量绑定流程，手动拆分注册各个服务，实现存储解耦：

// 1. 注册Identity核心服务，按现有规则配置密码校验逻辑
var identityBuilder = builder.Services.AddIdentityCore<ApplicationUser>(options =>
{
    // 匹配现有外部用户库的密码规则
    options.Password.RequireDigit = false;
});

// 2. 绑定外部只读用户Store到核心用户管理服务
identityBuilder.AddUserStore<ExternalReadOnlyUserStore>();

// 3. 注册内存版令牌存储，独立绑定令牌读写逻辑
builder.Services.AddScoped<IUserTokenStore<ApplicationUser>, InMemoryUserTokenStore>();

// 4. 接入JWT Bearer认证，禁用默认的Cookie认证流程
builder.Services.AddAuthentication(options =>
{
    options.DefaultScheme = JwtBearerDefaults.AuthenticationScheme;
})
.AddJwtBearer(); // 按原有JWT配置逻辑编写即可

• 全量注册流程是最大的踩坑点：默认的AddIdentity()、AddEntityFrameworkStores() 会把所有Identity存储接口一次性绑定到同一个实现上，很容易导致令牌存储也绑定到外部只读Store，触发写操作异常，必须手动拆分注册
• 内存令牌存储不需要做额外持久化，服务重启后令牌全部失效的特性完全符合业务要求，不需要额外适配
• 因为外部库是只读的，所有依赖用户写操作的功能（比如注册、修改密码、绑定外部登录）都会自然抛出不支持异常，和业务规则完全对齐

内容的提问来源于stack exchange，提问作者Christoph Mett