配置身份验证：.Configure<JwtBearerOptions>与.AddJwtBearer的区别

核心差异 #

1. 配置时机与作用阶段 #

• AddJwtBearer(Action<JwtBearerOptions>)：属于认证方案注册阶段的初始化配置。调用它时，系统会创建并绑定JWT Bearer认证方案的基础选项，是方案创建时的"初始设定"，执行后即作为该方案的默认配置基础。
• services.Configure<JwtBearerOptions>(schemeName, action)：属于已注册方案的后续调整配置。它不会创建新的认证方案，仅针对已注册好的JWT Bearer方案（比如通过AddMicrosoftIdentityWebApi或AddJwtBearer注册的），对其选项进行修改、补充或覆盖，可在注册方案后的任意阶段调用，甚至多次叠加执行。

2. 与第三方认证库的适配性 #

以你使用的Azure AD场景为例：

• 当使用AddMicrosoftIdentityWebApi时，该方法已内置Azure AD令牌验证的专属逻辑（比如v2.0令牌处理、租户自动发现、默认TokenValidationParameters设置等）。此时用Configure<JwtBearerOptions>，可以在微软库的默认配置基础上，仅修改你需要调整的部分（比如覆盖特定的TokenValidationParameters属性），无需完全重写所有配置。
• 若直接用AddJwtBearer手动配置，等于完全脱离微软Identity Web库的封装，所有Azure AD相关的验证逻辑都需要你手动实现（比如处理issuer格式、配置正确的Authority规则等），适合不需要依赖第三方库的原生JWT认证场景。

3. 配置优先级与叠加规则 #

• 如果先执行AddJwtBearer配置，后续再调用Configure<JwtBearerOptions>，后者的配置会覆盖前者中相同的属性（比如两者都设置了Authority，最终会用Configure里的值）。
• 若先通过AddMicrosoftIdentityWebApi注册方案，再用Configure调整，相当于在默认配置上做增量修改，未被修改的属性会保留微软库的默认值。

对应你的代码示例分析 #

• 第一种写法：借助AddMicrosoftIdentityWebApi快速接入Azure AD的认证能力，再通过Configure<JwtBearerOptions>微调关键配置（如TokenValidationParameters、Authority），适合需要复用Azure AD官方认证逻辑，但需自定义部分规则的场景。
• 第二种写法：完全手动配置JWT认证的核心参数，适合不需要依赖微软Identity Web库，希望完全掌控所有认证配置细节的场景。

内容的提问来源于stack exchange，提问作者Farid-EN