如何搭建仅依赖外部后端认证的ASP.NET Core 2.2解决方案

看起来你踩了AddDefaultIdentity的坑——这个方法是为本地用户管理场景封装的，自带了一堆默认依赖，所以才会逼你实现那些根本用不上的FindByNameAsync、GetPasswordHashAsync方法。针对你的需求（仅调用外部API做认证，无需本地用户存储），完全可以绕开这套沉重的封装，用更轻量的方式实现，同时也能解决自定义密码哈希的问题。

一、替换AddDefaultIdentity，用基础认证中间件实现 #

我们不需要Identity框架的本地用户管理能力，直接用AddAuthentication + Cookie认证方案即可，步骤如下：

1. 配置认证服务
   在Startup.cs（或Program.cs，.NET 6+）的服务配置代码里，替换原来的AddDefaultIdentity代码：

services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
    .AddCookie(options =>
    {
        options.LoginPath = "/Account/Login"; // 自定义登录页路径
        options.LogoutPath = "/Account/Logout";
        // 可按需添加Cookie过期时间、SameSite策略等配置
    });

2. 启用认证中间件
   在管道配置部分添加认证和授权中间件：

app.UseAuthentication();
app.UseAuthorization();

3. 自定义登录逻辑
   创建AccountController，编写登录的Post方法，直接调用外部API完成认证，同时处理密码哈希：

public class AccountController : Controller
{
    private readonly IExternalAuthApi _externalAuthApi; // 注入外部API客户端
    private readonly IPasswordHasher<object> _passwordHasher; // 自定义密码哈希器

    public AccountController(IExternalAuthApi externalAuthApi, IPasswordHasher<object> passwordHasher)
    {
        _externalAuthApi = externalAuthApi;
        _passwordHasher = passwordHasher;
    }

    [HttpPost]
    public async Task<IActionResult> Login(LoginViewModel model)
    {
        if (!ModelState.IsValid)
            return View(model);

        // 处理密码哈希：如果前端已完成哈希，直接用model.Password；否则用自定义哈希器处理
        var hashedPassword = _passwordHasher.HashPassword(null, model.Password);

        // 调用外部API的认证方法
        bool isAuthenticated = await _externalAuthApi.IsAuthenticated(model.Email, hashedPassword);

        if (isAuthenticated)
        {
            // 创建认证票据，可按需添加用户邮箱、角色等自定义Claims
            var claims = new List<Claim>
            {
                new Claim(ClaimTypes.Email, model.Email)
            };

            var claimsIdentity = new ClaimsIdentity(claims, CookieAuthenticationDefaults.AuthenticationScheme);
            var authProperties = new AuthenticationProperties
            {
                IsPersistent = model.RememberMe
            };

            await HttpContext.SignInAsync(CookieAuthenticationDefaults.AuthenticationScheme, new ClaimsPrincipal(claimsIdentity), authProperties);

            return RedirectToAction("Index", "Home");
        }

        ModelState.AddModelError(string.Empty, "Invalid email or password");
        return View(model);
    }

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

这样就完全不需要实现那些冗余的UserStore方法了，因为我们根本没用到Identity的本地用户管理模块。

二、自定义密码哈希器的注入 #

如果你需要统一的密码哈希逻辑（和前端算法一致），可以实现IPasswordHasher<T>接口，然后注入到服务中：

1. 实现自定义密码哈希器

public class CustomPasswordHasher : IPasswordHasher<object>
{
    public string HashPassword(object user, string password)
    {
        // 这里实现和前端一致的哈希算法，比如SHA256+盐值（如果需要）
        using var sha256 = SHA256.Create();
        var bytes = Encoding.UTF8.GetBytes(password); // 可按需拼接盐值
        var hashBytes = sha256.ComputeHash(bytes);
        return Convert.ToBase64String(hashBytes);
    }

    public PasswordVerificationResult VerifyHashedPassword(object user, string hashedPassword, string providedPassword)
    {
        // 验证逻辑：重新哈希输入密码，与传入的哈希值对比
        var providedHash = HashPassword(user, providedPassword);
        return providedHash.Equals(hashedPassword) ? PasswordVerificationResult.Success : PasswordVerificationResult.Failed;
    }
}

2. 注入到服务容器
   在服务配置代码里添加：

services.AddScoped<IPasswordHasher<object>, CustomPasswordHasher>();

如果你的场景中确实需要用到UserManager（不推荐，因为你不需要本地用户），也可以替换UserManager的默认密码哈希器：

services.AddIdentityCore<MyIdentityUser>(options => { })
    .AddPasswordValidator<PasswordValidator<MyIdentityUser>>()
    .AddUserValidator<UserValidator<MyIdentityUser>>()
    .AddPasswordHasher<CustomPasswordHasher>(); // 替换为自定义哈希器

三、为什么之前的方案会有冗余？ #

AddDefaultIdentity是ASP.NET Core Identity的高层封装，它默认绑定了UserStore、UserManager等一系列本地用户管理组件，这些组件依赖IUserStore<T>、IUserPasswordStore<T>等接口，所以你必须实现所有接口方法——哪怕你根本用不到本地存储。而我们上面的方案直接用底层的认证中间件，完全绕开了Identity的本地管理模块，只保留了Cookie认证的核心功能，完美匹配你的需求。

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