这种情况我之前也踩过坑，浏览器登录正常但密码模式调用失败，核心原因基本都是身份验证服务的配置差异或者请求细节的隐性区别，咱们一步步拆解排查：

1. 先确认密码授权类型是否被正确启用 #

Duende IdentityServer默认不会自动开启password授权类型，哪怕你客户端请求里指定了这个GrantType，服务端也会直接拒绝验证。你需要检查IdentityServer的Client配置中，AllowedGrantTypes是否明确包含密码模式：

new Client
{
    ClientId = "clientid",
    ClientName = "clientname",
    // 必须包含密码授权类型，也可以用GrantTypes.ResourceOwnerPassword直接指定
    AllowedGrantTypes = GrantTypes.ResourceOwnerPasswordAndClientCredentials,
    ClientSecrets = { new Secret("secret".Sha256()) },
    AllowedScopes = { "api1", "roles" }
}

如果这里漏了密码模式的配置，哪怕客户端参数全对，服务端也会判定用户验证失败。

2. 排查用户名/密码的隐性差异 #

浏览器登录时可能有自动修正逻辑（比如大小写自动匹配、表单自动去首尾空格），但代码里的参数是“硬编码”的，很容易出现细节错误：

• 检查代码里的UserName是否和实际用户名完全一致（包括大小写、特殊字符、空格），比如你浏览器用的是JohnDoe，但代码里写的是johndoe；
• 密码是否包含特殊字符（比如!@#$%^&*），虽然RequestPasswordTokenAsync会自动处理参数编码，但可以暂时换一个无特殊字符的测试密码验证；
• 日志里显示的UserName是username，是不是你代码里用了占位符，实际真实用户名写错了？

3. 对比浏览器登录与密码模式的用户验证逻辑 #

浏览器登录一般走的是ASP.NET Identity的Cookie认证（依赖SignInManager），而密码模式的资源所有者验证需要IdentityServer实现IResourceOwnerPasswordValidator接口。这两个逻辑必须完全一致，否则就会出现“一边通一边不通”的情况：

• 如果你自定义了IResourceOwnerPasswordValidator，检查里面的验证逻辑：是不是只允许用邮箱查找用户，而浏览器登录支持用户名/邮箱双登录？是不是额外要求用户必须处于启用状态（IsEnabled=true），但浏览器登录没做这个校验？
• 举个例子：如果你的自定义验证器里写了var user = await _userManager.FindByEmailAsync(userName);，但浏览器登录时用的是用户名，那密码模式肯定找不到对应用户；
• 另外还要确认：浏览器登录和密码模式用的是同一个用户存储实例，比如不会出现浏览器用生产库、密码模式用测试库的情况。

4. 检查客户端的权限与配置一致性 #

日志里已经显示ClientId是正确的，但还要确认两个关键点：

• ClientSecret是否和IdentityServer配置的一致？如果服务端配置的是哈希后的Secret（比如new Secret("secret".Sha256())），客户端传明文"secret"是没问题的；但如果服务端是明文存储（不推荐），客户端也必须传明文；
• AllowedScopes是否包含"api1"和"roles"？日志里Scopes是对的，但如果Client配置里没加这些Scope，也可能间接导致验证失败（不过你的错误提示是用户名密码问题，这个优先级稍低，但还是要确认）。

5. 排查请求的参数格式与重定向问题 #

你代码里设置了AllowAutoRedirect = true，但/connect/token端点是直接返回JSON的，不需要重定向，反而可能因为重定向导致参数丢失：

• 试试把AllowAutoRedirect设为false，避免不必要的重定向干扰；
• 用Postman直接模拟请求：向https://localhost:44328/connect/token发送POST请求，Content-Type设为application/x-www-form-urlencoded，参数填grant_type=password&username=你的真实用户名&password=你的真实密码&scope=api1 roles&client_id=clientid&client_secret=secret，看能不能拿到Token：
  • 如果Postman也失败：那肯定是服务端配置问题，回到前面的步骤重点排查；
  • 如果Postman成功：那就是代码里的HttpClient配置问题，比如代理、证书验证等影响了请求。

6. 开启更详细的服务端日志定位问题 #

Duende IdentityServer的默认日志级别可能不够细，你可以在appsettings.json里把日志级别设为Debug，这样能看到IResourceOwnerPasswordValidator的执行细节：

"Logging": {
  "LogLevel": {
    "Duende.IdentityServer": "Debug",
    "Microsoft.AspNetCore.Authentication": "Debug"
  }
}

开启后，你能看到服务端到底是怎么查找用户的，是真的没找到用户，还是验证时触发了其他规则（比如用户被锁定、自定义Claim校验不通过）。

最后建议你先从最简单的测试入手：用一个确定正确的测试账号（比如用户名test，密码Test123!），在Postman里模拟请求，同时看服务端Debug日志，定位到具体的失败节点，这样比盲目猜问题高效多了！