ASP.NET Core 3.1如何使用现有用户表替代AspNetUsers实现登录认证

完全可以，不需要依赖ASP.NET Core Identity默认生成的AspNetUsers表，也不需要对现有只读数据库做任何结构、数据修改，就能完成安全的登录校验。
结合你仅需要登录校验、不需要注册/找回密码等附加功能、数据库仅开放只读权限的场景，优先选择轻量Cookie认证方案，实现简单、无冗余依赖，也不会产生任何数据库写操作；如果后续需要用到Identity的角色管控、第三方登录等高级能力，也可以通过自定义Identity存储层适配现有表。

方案1：轻量Cookie认证实现（最匹配当前需求） #

这个方案不需要引入完整的Microsoft.AspNetCore.Identity相关包，直接基于ASP.NET Core内置的Cookie认证能力实现，从底层规避对数据库的写操作。

实现步骤 #

• 第一步：在Startup.cs中注册认证服务，配置Cookie认证规则

public void ConfigureServices(IServiceCollection services)
{
    // 注册Cookie认证为默认认证方案
    services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
        .AddCookie(options =>
        {
            options.LoginPath = "/Account/Login";
            options.AccessDeniedPath = "/Account/AccessDenied";
            // Cookie安全配置
            options.Cookie.HttpOnly = true;
            options.Cookie.SameSite = SameSiteMode.Lax;
            // 生产环境部署时改为CookieSecurePolicy.Always，强制HTTPS传输Cookie
            options.Cookie.SecurePolicy = CookieSecurePolicy.SameAsRequest;
            options.ExpireTimeSpan = TimeSpan.FromHours(2);
        });
    services.AddControllersWithViews();
    // 注册只读数据库上下文
    services.AddDbContext<ReadOnlyUserDbContext>(options =>
        options.UseSqlServer(Configuration.GetConnectionString("UserDbConnection")));
}

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    // 其他中间件配置...
    app.UseRouting();
    // 注意认证、授权中间件的顺序不能错，必须在UseRouting之后、UseEndpoints之前
    app.UseAuthentication();
    app.UseAuthorization();
    app.UseEndpoints(endpoints =>
    {
        endpoints.MapControllerRoute(
            name: "default",
            pattern: "{controller=Home}/{action=Index}/{id?}");
    });
}

• 第二步：定义只读数据库上下文和用户实体，从代码层面阻止所有写操作

// 用户实体，字段和现有用户表完全一一对应
public class ExistingUser
{
    public string Id { get; set; }
    public string Name { get; set; }
    public int Rank { get; set; }
    public string Password { get; set; }
    public string Email { get; set; }
    public string Phone { get; set; }
}

public class ReadOnlyUserDbContext : DbContext
{
    public ReadOnlyUserDbContext(DbContextOptions<ReadOnlyUserDbContext> options) : base(options)
    {
        // 全局开启无追踪查询，避免EF Core产生隐式状态变更
        ChangeTracker.QueryTrackingBehavior = QueryTrackingBehavior.NoTracking;
    }

    public DbSet<ExistingUser> ExistingUsers { get; set; }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        // 映射实际数据库中的用户表，不要添加任何新字段、索引、约束
        modelBuilder.Entity<ExistingUser>(entity =>
        {
            entity.ToTable("替换为实际数据库中的用户表名");
            entity.HasKey(e => e.Id);
            // 字段长度按实际表结构配置即可
            entity.Property(e => e.Id).HasColumnType("varchar(50)");
            entity.Property(e => e.Name).HasColumnType("varchar(50)");
            entity.Property(e => e.Password).HasColumnType("varchar(200)");
            entity.Property(e => e.Email).HasColumnType("varchar(100)");
            entity.Property(e => e.Phone).HasColumnType("varchar(20)");
        });
    }

    // 重写所有保存方法，直接抛出异常，从根源阻断所有写操作
    public override int SaveChanges() => throw new InvalidOperationException("当前数据库为只读，不支持数据修改");
    public override int SaveChanges(bool acceptAllChangesOnSuccess) => throw new InvalidOperationException("当前数据库为只读，不支持数据修改");
    public override Task<int> SaveChangesAsync(CancellationToken cancellationToken = default) => throw new InvalidOperationException("当前数据库为只读，不支持数据修改");
    public override Task<int> SaveChangesAsync(bool acceptAllChangesOnSuccess, CancellationToken cancellationToken = default) => throw new InvalidOperationException("当前数据库为只读，不支持数据修改");
}

• 第三步：实现登录、登出逻辑

注意：密码校验必须严格对齐原有用户系统的密码存储规则：如果是明文存储直接比对即可（生产环境强烈不推荐，后续拿到库权限请第一时间改为带盐强哈希存储）；如果是哈希存储（比如带盐MD5、PBKDF2、SHA256等），必须使用和原有系统完全一致的哈希逻辑校验，不要自行修改算法。

public class AccountController : Controller
{
    private readonly ReadOnlyUserDbContext _dbContext;
    public AccountController(ReadOnlyUserDbContext dbContext)
    {
        _dbContext = dbContext;
    }

    [HttpGet]
    public IActionResult Login() => View();

    [HttpPost]
    [ValidateAntiForgeryToken]
    public async Task<IActionResult> Login(string account, string password, bool rememberMe)
    {
        if (string.IsNullOrWhiteSpace(account) || string.IsNullOrWhiteSpace(password))
        {
            ModelState.AddModelError(string.Empty, "账号或密码错误");
            return View();
        }
        // 支持用户名/邮箱/手机号登录，按实际需求调整匹配规则
        var user = await _dbContext.ExistingUsers.FirstOrDefaultAsync(u =>
            u.Name == account || u.Email == account || u.Phone == account);
        if (user == null)
        {
            // 统一返回模糊提示，不要明确区分"用户不存在"和"密码错误"，避免用户枚举攻击
            ModelState.AddModelError(string.Empty, "账号或密码错误");
            return View();
        }
        // 密码校验逻辑，替换为你实际的密码比对规则
        bool passwordValid = user.Password == password;
        if (!passwordValid)
        {
            ModelState.AddModelError(string.Empty, "账号或密码错误");
            return View();
        }
        // 构造用户身份声明，把后续授权需要的信息写入Cookie
        var claims = new List<Claim>
        {
            new Claim(ClaimTypes.NameIdentifier, user.Id),
            new Claim(ClaimTypes.Name, user.Name),
            new Claim("UserRank", user.Rank.ToString()),
            new Claim(ClaimTypes.Email, user.Email ?? string.Empty),
            new Claim(ClaimTypes.MobilePhone, user.Phone ?? string.Empty)
        };
        var identity = new ClaimsIdentity(claims, CookieAuthenticationDefaults.AuthenticationScheme);
        var properties = new AuthenticationProperties
        {
            IsPersistent = rememberMe,
            ExpiresUtc = DateTimeOffset.UtcNow.AddHours(rememberMe ? 168 : 2)
        };
        await HttpContext.SignInAsync(CookieAuthenticationDefaults.AuthenticationScheme,
            new ClaimsPrincipal(identity), properties);
        return RedirectToAction("Index", "Home");
    }

    [HttpPost]
    [ValidateAntiForgeryToken]
    public async Task<IActionResult> Logout()
    {
        await HttpContext.SignOutAsync(CookieAuthenticationDefaults.AuthenticationScheme);
        return RedirectToAction("Login");
    }
}

方案2：自定义Identity存储适配（适合需要Identity高级能力的场景） #

如果你后续需要用到Identity的角色授权、安全戳校验、第三方登录等能力，可以自定义IUserStore<IdentityUser>实现，直接读取现有用户表的数据。因为你只有数据库只读权限，只需要把IUserStore中所有涉及写操作的方法（CreateAsync、UpdateAsync、DeleteAsync、ResetPasswordAsync等）直接抛出NotSupportedException即可，不会对数据库产生任何修改。
这个方案需要实现的接口较多，代码量较大，如果你只需要基础登录功能不推荐使用。

安全注意事项 #

• 所有登录相关请求必须强制HTTPS，避免密码、认证Cookie在传输过程中被窃听
• 登录接口必须添加IP频率限制、人机校验机制，防止暴力破解密码
• Cookie必须开启HttpOnly属性，生产环境开启Secure属性，降低XSS、中间人攻击的风险
• 不要在登录失败时返回明确的错误提示区分用户不存在和密码错误，统一返回模糊的“账号或密码错误”
• 不要给数据库连接账号分配任何写权限，配合代码层的只读上下文做双重保障，避免误写数据
• 如果现有密码为明文存储，在后续获得数据库修改权限后，第一时间将密码替换为带盐的强哈希值（比如使用PasswordHasher默认的PBKDF2算法）存储

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