Blazor授权核心是后端定义角色策略并确保角色写入Claims、前端用AuthorizeView/特性/代码控制访问。需验证JWT含roles声明，Azure AD配groupMembershipClaims，Identity用户须AddToRoleAsync绑定角色。

Blazor 中配置授权和角色，核心是两件事：后端定义角色与策略、前端控制访问逻辑。关键不在“能不能做”，而在于前后端职责是否清晰、角色数据是否真正落地到 Claims 中。

后端：注册角色并注入授权策略

在 Program.cs（.NET 6+）中完成以下三步：

• 启用 Identity 并添加角色支持：builder.Services.AddIdentityCore().AddRoles().AddEntityFrameworkStores();
• 注册授权服务并定义角色策略，例如：
  

  builder.Services.AddAuthorization(options => {
  
    options.AddPolicy("AdminOnly", p => p.RequireRole("Administrator"));
  
    options.AddPolicy("EditorOrAdmin", p => p.RequireRole("Editor", "Administrator"));
  
  });

• 确保用户登录时，角色信息被写入 Claims —— 这通常由 SignInManager 自动完成；若用 JWT 或 Azure AD，则需确认 ID Token 或 Access Token 中包含 roles 声明，并在 TokenValidationParameters 中启用 MapInboundClaims = false（避免 ASP.NET Core 默认剥离 roles）。

前端：用三种方式控制可见性与访问

Blazor WebAssembly 或 Server 都适用，但注意：WASM 中的授权检查是客户端行为，仅用于 UX 层遮蔽，真实权限必须由 API 层二次校验。

• 页面级控制：在 Razor 组件顶部加特性，如
  

  @page "/settings"
  @attribute [Authorize(Roles = "Administrator")]

• 组件级控制：用 包裹内容，支持 Roles、Policy 或自定义条件：
  

  
    
    
  无编辑权限
  

• 代码中动态判断：注入 AuthenticationStateProvider，调用 user.IsInRole("...") 或 AuthorizationService.AuthorizeAsync(...) 获取细粒度结果。

常见坑点与验证建议

很多问题不是配置错，而是没看到角色到底有没有传过来。

• 检查浏览器开发者工具 → Application → Cookies 或 Local Storage 中的 token（WASM）或服务器响应头（Server），解码 JWT 确认 payload 含 "roles": ["Administrator"]；
• 若用 Azure AD，必须在应用注册的 “Manifest” 中设置 "groupMembershipClaims": "All" 或显式配置 App Roles 并在用户/组中分配；
• 本地 Identity 用户需手动调用 UserManager.AddToRoleAsync(user, "Administrator")，不能只建 Role 不绑定；
• Blazor Server 中，每次导航都走服务端授权，更安全；WASM 中，AuthorizeView 依赖客户端解析的 Claims，刷新页面后需重新拉取状态。

基本上就这些。角色本身不复杂，但容易忽略 Claims 是否真实存在、策略名是否拼写一致、以及前后端对“角色”理解是否统一。