Blazor授权核心是后端定义角色策略并确保角色写入Claims、前端用AuthorizeView/特性/代码控制访问。需验证JWT含roles声明，Azure AD配groupMembershipClaims，Identity用户须AddToRoleAsync绑定角色。
Blazor 中配置授权和角色，核心是两件事：后端定义角色与策略、前端控制访问逻辑。关键不在“能不能做”，而在于前后端职责是否清晰、角色数据是否真正落地到 Claims 中。
后端：注册角色并注入授权策略
在 Program.cs（.NET 6+）中完成以下三步：
- 启用 Identity 并添加角色支持：
builder.Services.AddIdentityCore<IdentityUser>().AddRoles<IdentityRole>().AddEntityFrameworkStores<ApplicationDbContext>(); - 注册授权服务并定义角色策略，例如：
builder.Services.AddAuthorization(options => {<br> options.AddPolicy("AdminOnly", p => p.RequireRole("Administrator"));<br> options.AddPolicy("EditorOrAdmin", p => p.RequireRole("Editor", "Administrator"));<br> }); - 确保用户登录时，角色信息被写入 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"<br>@attribute [Authorize(Roles = "Administrator")]
-
组件级控制：用
<AuthorizeView>包裹内容，支持 Roles、Policy 或自定义条件：<AuthorizeView Roles="Administrator,Editor"><br> <Authorized><EditButton /></Authorized><br> <NotAuthorized><p>无编辑权限</p></NotAuthorized><br></AuthorizeView>
-
代码中动态判断：注入
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 是否真实存在、策略名是否拼写一致、以及前后端对“角色”理解是否统一。
