配置JwtBearerOptions的Authority属性时触发500内部服务器错误的原因及解决咨询

我来帮你拆解下这个问题的来龙去脉：当你给JwtBearerOptions设置Authority = "https://localhost:7089/"时出现500错误，注释掉就恢复正常，核心原因是你误解了Authority的作用场景，当前你的服务架构完全不需要这个配置。

问题成因拆解 #

从错误堆栈里的关键信息就能找到根因：

System.InvalidOperationException: IDX20803: Unable to obtain configuration from: 'System.String'.
---> System.NotSupportedException: The 'localhost' scheme is not supported.

这里的本质不是localhost协议不支持，而是当你设置Authority后，JwtBearer中间件会自动尝试去这个地址获取OpenID Connect的配置文档（通常是/.well-known/openid-configuration），用来获取验证JWT所需的公钥、Issuer规则等信息。但你的https://localhost:7089/服务只是自己写了生成JWT的接口，并非标准的身份认证服务，根本没有提供这个配置端点，所以中间件请求失败，直接抛出了500错误。

另外，Authority的设计是给依赖第三方身份提供者（比如IdentityServer、Azure AD）的场景用的：当你的Token是从这些专业IdP颁发的，中间件可以通过Authority自动拉取验证规则，不用手动配置TokenValidationParameters里的密钥等信息。但你现在是自己生成JWT、自己用对称密钥验证，完全不需要依赖外部IdP的配置，所以Authority对你来说是多余的。

更关键的是：当你同时设置Authority和TokenValidationParameters时，中间件会优先使用从Authority获取的配置，忽略你手动设置的IssuerSigningKey等参数，这进一步导致验证流程彻底失败。

解决办法 #

根据你的当前场景，最直接的解决方式就是保持Authority配置被注释的状态，因为你已经在TokenValidationParameters里明确指定了：

• ValidIssuer和ValidAudience（和生成Token时的参数完全一致）
• IssuerSigningKey（和生成Token时用的对称密钥完全一致）
  这些配置已经足够让中间件正确验证你自己生成的JWT了。

如果后续你打算切换到标准的身份认证服务（比如用IdentityServer搭建自己的IdP），那时候再设置Authority，并且确保该服务能正常返回OpenID Connect配置文档即可。

代码优化小建议 #

顺便提个小细节：你生成Token时，claims数组定义了new Claim(ClaimTypes.Email , "test@test.com")，但在tokenDescriptor.Subject里又单独加了new Claim("Id", "testID")，其实可以合并到一个ClaimsIdentity里，让代码更整洁：

var claims = new List<Claim>
{
    new Claim("Id", "testID"),
    new Claim(ClaimTypes.Email, "test@test.com")
};
var tokenDescriptor = new SecurityTokenDescriptor()
{
    Subject = new ClaimsIdentity(claims),
    // 其他配置...
};

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