将角色从ASP.NET Web API传递到Core MVC以支持Authorize特性

角色完全可以通过Claim承载，且这是ASP.NET Core体系下的标准实现方式，不需要额外做自定义权限映射，就能达到和站点直连数据库完全一致的权限使用体验，按以下步骤落地即可：

一、Web API端的身份输出规范 #

• 所有身份校验逻辑全部在API端完成，校验通过后，将用户所属角色写入标准role类型Claim，ClaimType固定使用http://schemas.microsoft.com/ws/2008/06/identity/claims/role，不要自定义角色Claim类型，避免MVC端默认授权逻辑无法识别。
• 除角色Claim外，同步返回标准用户标识Claim：Name（用户名）、NameIdentifier（用户ID），保证MVC端User.Identity.Name等内置属性可正常取值。
• 登录接口返回结构直接包含完整的Claim集合即可，如果用JWT做API间传输凭证，直接把上述Claim写入JWT的Payload，同时做好JWT签名校验配置。

二、MVC端认证核心配置 #

这一步是保证授权特性、视图权限判断和原生体验一致的关键：

• MVC端不实现独立的账号密码校验逻辑，所有登录请求全部转发到Web API做校验。
• 拿到API返回的Claim集合（或校验通过API返回的JWT、解析出其中的Claim）后，直接调用内置的HttpContext.SignInAsync方法签发本地HttpOnly认证Cookie，不要在这一步额外查询数据库补全角色信息，示例代码：

// 调用Web API完成登录校验，获取返回的Claim集合
var loginResponse = await _webApiClient.Login(loginViewModel);
if (!loginResponse.IsSuccess)
{
    ModelState.AddModelError(string.Empty, "账号或密码错误");
    return View(loginViewModel);
}
// 用API返回的Claim构建身份凭证
var identity = new ClaimsIdentity(
    loginResponse.Claims,
    CookieAuthenticationDefaults.AuthenticationScheme
);
// 签发本地认证Cookie，后续请求会自动完成身份、角色绑定
await HttpContext.SignInAsync(
    CookieAuthenticationDefaults.AuthenticationScheme,
    new ClaimsPrincipal(identity)
);

• Program.cs中正常添加Cookie认证和授权服务即可，不需要做特殊的角色映射配置：

builder.Services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
    .AddCookie(options =>
    {
        options.LoginPath = "/Account/Login";
        options.AccessDeniedPath = "/Account/AccessDenied";
        options.ExpireTimeSpan = TimeSpan.FromMinutes(20);
        options.SlidingExpiration = true;
    });
builder.Services.AddAuthorization();

• 配置完成后，控制器/Action上的[Authorize(Roles = "Admin,Editor")]特性会直接生效，和直连数据库取角色的校验逻辑完全一致。

三、视图层细粒度权限控制 #

视图层不需要做任何自定义封装，直接用内置的权限判断方法即可实现菜单过滤、按钮禁用等效果，和直连数据库的用法完全相同：

<!-- 菜单按角色过滤 -->
@if (User.IsInRole("Admin"))
{
    <li class="nav-item">
        <a class="nav-link" asp-controller="System" asp-action="UserList">用户管理</a>
    </li>
}

<!-- 按钮按角色控制显隐/禁用 -->
@if (User.IsInRole("Editor") || User.IsInRole("Admin"))
{
    <button class="btn btn-primary" id="publishBtn">发布文章</button>
}
else
{
    <button class="btn btn-secondary" disabled>发布文章（无权限）</button>
}

如果需要做更复杂的授权规则，直接用内置的策略授权配置即可，策略判断直接读取已加载的Claim，不需要额外查库：

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("CanDeletePost", policy => 
        policy.RequireRole("Admin", "SeniorEditor"));
});

对应视图中直接用User.HasClaim或注入IAuthorizationService做校验即可。

四、避坑说明 #

• 不要自定义角色ClaimType，除非你在构建ClaimsIdentity时显式指定RoleClaimType参数，否则User.IsInRole()和Authorize特性都无法识别角色信息，这是最常见的配置错误。
• 角色变更场景不需要做复杂的实时同步，利用Cookie的滑动刷新机制，在Cookie刷新事件中静默调用Web API拉取最新的用户角色Claim，重新签发Cookie即可，用户无感知，也能保证角色信息不会长时间不一致。
• 不要把API返回的JWT直接存储到前端LocalStorage或非HttpOnly Cookie中，MVC签发的本地认证Cookie默认开启HttpOnly，安全性更高。
• 如果后续需要接入更多客户端，再考虑引入标准OIDC协议层，当前测试场景用上述Claim透传+本地Cookie签发的方案代码量最少，和ASP.NET Core原生授权体系适配度最高，没有额外的兼容成本。

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