.NET 5.0 Web API无数据库单用户场景下JWT认证方案咨询

你完全不需要自定义UserManager和UserStore——这两个组件是ASP.NET Core Identity体系的组成部分，本身是为多用户管理、密码重置、双因素认证、第三方登录这类复杂身份场景设计的，你当前单用户、轻量API的场景引入这套属于典型的过度设计，只会平白增加不必要的依赖和维护成本。
直接把凭证做安全处理后存在配置文件里是可行的，但要注意存储方式符合安全规范，不要裸存明文或者可逆加密的密码。

具体实现步骤 #

• 凭证存储
  不要自己造加密逻辑，直接用微软内置的PasswordHasher类（不需要额外安装NuGet包，随ASP.NET Core基础框架自带），它默认实现了符合行业安全标准的PBKDF2哈希算法，自带随机盐值处理，足够应对单用户场景的安全要求。
  首次部署前，本地单独跑一段代码生成密码哈希值：

  // 仅本地执行一次，生成后即可丢弃明文密码
  var passwordHasher = new PasswordHasher<object>();
  string adminPassword = "你设置的强密码（建议12位以上，包含大小写、数字、特殊字符）";
  string storedHash = passwordHasher.HashPassword(null, adminPassword);
  

  把生成的storedHash和固定的用户名存在appsettings.json里，生产环境建议把这类敏感配置放到环境变量或者服务器的密钥存储服务中，不要硬编码在代码里提交到版本仓库。
• 登录接口逻辑
  不需要注册Identity相关中间件，单独写一个匿名访问的登录接口即可：
  1. 接收请求传入的用户名、密码参数
  2. 从配置中读取预存的合法用户名、密码哈希
  3. 先比对用户名是否匹配，不匹配直接返回401
  4. 调用PasswordHasher.VerifyHashedPassword方法比对传入密码和存储的哈希值，验证通过就按常规逻辑签发JWT令牌，不通过返回401
     核心验证代码参考：

  var verifyResult = passwordHasher.VerifyHashedPassword(null, appConfig.StoredPasswordHash, request.Password);
  if (verifyResult != PasswordVerificationResult.Success || request.Username != appConfig.StoredUsername)
  {
      return Unauthorized("用户名或密码错误");
  }
  // 验证通过后，按你预设的JWT配置（签名密钥、过期时间、声明信息）生成令牌返回即可
  

• JWT配置注意事项
  JWT的签名密钥至少使用32位长度的随机字符串，不要用短弱密钥，生产环境和开发环境使用不同的签名密钥；令牌过期时间不要设置过长，普通内部API场景建议设置为15分钟到2小时，单用户场景如果嫌刷新麻烦可以适当延长，但不要超过7天。

不推荐的做法避坑 #

• 不要为了单用户场景强行接入ASP.NET Core Identity、自定义UserStore：要实现自定义Store必须实现一整套Identity规定的接口，还要引入Identity的整套中间件依赖，和你不想引入EF Core、保持项目轻量的需求完全相悖，后续框架版本升级还要跟着适配Identity的接口变更，维护成本很高。
• 不要在配置中存储明文密码、或者使用可逆加密算法存储密码：一旦配置文件泄露，这类存储方式会直接暴露用户凭证；使用单向哈希存储的话，哪怕哈希值泄露，攻击者也无法在合理时间内反推出明文密码。
• 不要自研密码哈希逻辑：非安全专业出身的开发者写的哈希逻辑普遍存在盐值固定、迭代次数不足、使用过时加密算法的问题，很容易被暴力破解，直接用微软内置的经过安全审计的实现是成本最低、安全性最高的选择。

如果后续业务扩展需要支持多用户、细粒度权限、第三方登录等能力，再考虑接入Identity体系、实现自定义存储层即可，当前阶段不需要提前做这类冗余的扩展性设计。

内容的提问来源于stack exchange，提问作者Kacper M.