FastEndpoints 5.31.0版本中JWT认证配置的改进

在FastEndpoints 5.31.0版本中，JWT认证配置功能得到了重要改进。这个改进主要针对AddAuthenticationJwtBearer方法的配置方式进行了优化，使其更加符合.NET生态系统的配置习惯。

原有配置方式的局限性

在之前的版本中，AddAuthenticationJwtBearer方法会创建一个新的JwtSigningOptions实例，然后通过传入的Action对其进行配置。这种方式虽然简单直接，但在某些场景下存在不便之处：

1. 当JWT配置参数需要从多个来源获取时，配置逻辑会变得复杂
2. 无法利用.NET Core强大的依赖注入系统来管理配置
3. 与其他配置方式不一致，增加了学习成本

新版本的核心改进

5.31.0版本引入了以下重要改进：

1. AddAuthenticationJwtBearer方法现在会首先检查DI容器中是否已经注册了JwtSigningOptions服务
2. 如果找到已注册的服务，将使用该实例作为基础配置
3. 仍然支持通过Action进行额外配置，这会在DI提供的配置基础上进行

实际应用示例

假设我们有一个自定义的JWT配置类：

public class JwtSettings {
    public const string SectionName = "JWT";
    public string Key { get; set; }
    public int Duration { get; set; } = 3600;
}

在5.31.0版本中，我们可以这样配置：

// 首先注册自定义配置
builder.Services.AddOptions<JwtSettings>()
    .BindConfiguration(JwtSettings.SectionName)
    .Validate(o => o.Key != null, "必须提供JWT密钥")
    .ValidateOnStart();

// 通过DI配置JwtSigningOptions
builder.Services.AddOptions<JwtSigningOptions>()
    .Configure<JwtSettings>((options, settings) => {
        options.SigningKey = settings.Key;
        // 其他配置...
    });

// 添加认证服务
builder.Services.AddAuthenticationJwtBearer(_ => {});

技术优势

这种改进带来了几个显著优势：

1. 配置集中管理：所有JWT相关配置可以集中在一个地方管理
2. 验证前置：可以在服务启动时就验证配置的有效性
3. 灵活性：既支持通过DI配置，也支持通过Action覆盖
4. 一致性：与ASP.NET Core其他组件的配置方式保持一致

相关改进

值得注意的是，这个版本还对JwtCreationOptions进行了类似的改进，使得JWT生成相关的配置也可以采用同样的模式进行管理。

总结

FastEndpoints 5.31.0版本对JWT认证配置的改进，使得开发者可以更灵活、更符合习惯地管理JWT相关配置。这种改进不仅提升了开发体验，也使得FastEndpoints更好地融入了.NET生态系统。对于需要从多种来源获取配置参数，或者需要在应用启动时验证配置有效性的场景，这一改进尤为重要。