ASP.NET Core Web应用基于Microsoft Identity的Azure Bearer Token认证问题

• 当前Web应用仅注册了OpenID Connect交互认证方案，这套方案默认会把所有未通过Cookie校验的请求，302重定向到微软交互登录页，完全不会解析请求头中携带的Bearer Token
• 这套OIDC方案的默认行为是未认证时返回302重定向，而非401状态码，所以才会出现请求带了合法Token、却返回登录页HTML的现象
• 认知误区澄清：Microsoft.Identity.Web 框架原生支持同时启用Web UI交互认证和API接口的Bearer Token校验，完全不需要切换成独立的纯JwtBearer配置，你现有的AAD自定义应用角色、基于角色的访问控制逻辑可以100%复用
• 即便你通过Postman成功获取了合法的Bearer Token，因为Web应用没有对应的Bearer校验逻辑，请求会被直接判定为未登录的浏览器导航请求，最终返回微软登录页HTML内容

1. 修改Startup.cs的认证服务注册逻辑 #

将原有的单方案认证注册，替换为同时支持Web UI交互认证、API Bearer Token校验的双方案注册：
原代码：

services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApp(Configuration.GetSection("AzureAd"));

替换为：

services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
    // 新增API Bearer Token校验支持
    .AddMicrosoftIdentityWebApi(Configuration.GetSection("AzureAd"))
    // 保留原有Web UI交互认证
    .AddMicrosoftIdentityWebApp(Configuration.GetSection("AzureAd"));

这里的AddMicrosoftIdentityWebApi是官方封装的JWT校验逻辑，会自动映射AAD应用注册里配置的自定义应用角色Claim，完全兼容你现有写的RequireRole("ADMIN", "USER")这类授权策略，不会破坏原有UI页面的权限判断流程。

2. 调整API控制器的授权配置 #

原授权策略默认绑定Cookie/OIDC方案，会导致Bearer请求被直接重定向到登录页。需要给API控制器明确指定支持的认证方案：
原控制器代码：

[Authorize("AllRoles")]
[Route("api/[controller]")]
[ApiController]
public class HealthCheckController : ControllerBase

修改为：

// 同时支持两种认证方式：浏览器Cookie登录、接口Bearer Token登录，继承原有角色校验规则
[Authorize(Policy = "AllRoles", AuthenticationSchemes = "Bearer, OpenIdConnect")]
[Route("api/[controller]")]
[ApiController]
public class HealthCheckController : ControllerBase

配置后，框架处理API请求时会优先解析请求头中的Bearer Token，存在合法Token时直接走JWT校验流程；无有效Token时再回退到Cookie/OIDC交互登录流程。

3. 补全AAD应用注册配置 #

• 为Postman专用的第二个应用注册配置API权限时，必须选择**应用权限（非委托权限）**类型，选中你Web应用定义的ADMIN自定义角色，配置完成后必须点击「授予管理员同意」，否则获取的Token不会携带对应的角色Claim
• 确认Postman取Token时填写的resource值，和Web应用对应应用注册的「公开API」选项卡下的应用ID URI完全一致
• 补全appsettings.json中AzureAd:Domain字段的值，填写租户对应的AAD域名（格式如xxx.onmicrosoft.com），避免Token校验时的签发方匹配失败

4. 验证排查 #

• 把Postman获取到的Token放到公开JWT解析工具中检查，确认roles字段内包含配置的ADMIN角色，否则说明AAD侧的权限同意配置未生效
• 不要将API端点的授权策略单独绑定到Cookie认证方案，否则携带Bearer Token的请求永远会被重定向到交互登录页

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