Blazor WebAssembly客户端应用中Authorization View角色授权不生效问题排查

看起来你的问题出在角色声明的格式上——Azure AD返回的roles声明是一个JSON数组字符串（比如["Administrator"]），但Blazor的AuthorizeView组件默认期望每个角色是一个独立的Claim条目，而不是单个Claim里的数组值。

下面是具体的问题排查和解决步骤：

为什么AuthorizeView不生效？ #

当你登录后，你的ClaimsPrincipal里只有一个类型为roles的Claim，它的值是整个JSON数组字符串，而不是每个角色单独作为一个Claim。AspNetCore的授权系统在检查角色时，会查找是否存在类型匹配且值完全等于目标角色的Claim，所以自然识别不到Administrator这个角色。

解决方案：自定义ClaimsPrincipal工厂来拆分角色数组 #

我们可以通过自定义AccountClaimsPrincipalFactory，在创建用户身份时自动将roles数组拆分成多个独立的角色Claim。

步骤1：创建自定义ClaimsPrincipal工厂 #

using Microsoft.AspNetCore.Components.WebAssembly.Authentication;
using System.Security.Claims;
using System.Text.Json;

public class CustomMsalAccountClaimsPrincipalFactory : AccountClaimsPrincipalFactory<RemoteUserAccount>
{
    public CustomMsalAccountClaimsPrincipalFactory(IAccessTokenProviderAccessor accessor) 
        : base(accessor)
    {
    }

    public override async ValueTask<ClaimsPrincipal> CreateUserAsync(RemoteUserAccount account, RemoteAuthenticationUserOptions options)
    {
        // 先获取默认生成的ClaimsPrincipal
        var user = await base.CreateUserAsync(account, options);

        if (user.Identity.IsAuthenticated)
        {
            var identity = (ClaimsIdentity)user.Identity;
            
            // 从account的附加属性中获取roles（Azure AD通常会把roles放在这里）
            if (account.AdditionalProperties.TryGetValue("roles", out var rolesValue))
            {
                // 处理JSON数组类型的roles
                if (rolesValue is JsonElement rolesElement && rolesElement.ValueKind == JsonValueKind.Array)
                {
                    foreach (var roleElement in rolesElement.EnumerateArray())
                    {
                        var role = roleElement.GetString();
                        if (!string.IsNullOrEmpty(role))
                        {
                            identity.AddClaim(new Claim(options.RoleClaim, role));
                        }
                    }
                }
                // 兼容字符串形式的JSON数组（如果你的场景是这种情况）
                else if (rolesValue is string rolesString)
                {
                    try
                    {
                        var roles = JsonSerializer.Deserialize<List<string>>(rolesString);
                        foreach (var role in roles)
                        {
                            identity.AddClaim(new Claim(options.RoleClaim, role));
                        }
                    }
                    catch { /* 解析失败时忽略，保持原状态 */ }
                }
            }
        }

        return user;
    }
}

步骤2：注册自定义工厂到DI容器 #

在你的Program.cs里，修改MsalAuthentication的注册代码，添加自定义的工厂：

builder.Services.AddMsalAuthentication(options => {
    builder.Configuration.Bind("AzureAd", options.ProviderOptions.Authentication);
    options.ProviderOptions.DefaultAccessTokenScopes.Add(myAPI);
    options.UserOptions.RoleClaim = "roles";
})
// 添加这一行，注册自定义的ClaimsPrincipal工厂
.AddAccountClaimsPrincipalFactory<CustomMsalAccountClaimsPrincipalFactory>();

验证是否生效 #

修改后，重新登录应用，你可以在UserClaimsBase的_claims里看到每个角色都变成了独立的Claim条目（比如一个类型为roles、值为Administrator的Claim），此时<AuthorizeView Roles="Administrator">ADMIN UI</AuthorizeView>应该就能正常显示对应的UI了。

额外检查点 #

1. 确保Azure AD应用注册的ID Token配置中包含roles声明：在Azure Portal的应用注册→令牌配置里，确认已添加roles作为ID令牌的可选声明。
2. 确认用户确实被分配了对应的角色：在Azure Portal的企业应用→你的应用→用户和组里，检查用户的角色分配是否正确。

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