是否应自定义RemoteAuthenticatorView？Blazor WASM多身份认证疑问

当前自定义方案的合理性与安全风险 #

你通过自定义AuthorizeView、AuthenticationStateProvider和RemoteAuthenticatorView实现双认证的思路是可行的，但需重点关注以下安全细节：

• 令牌存储风险：如果直接用localStorage存储内部OIDC令牌，存在XSS窃取风险，必须改用Blazor内置的ProtectedLocalStorage做加密存储。
• 令牌验证缺失：必须对内部服务返回的JWT令牌做完整验证——包括签名有效性、发行方（iss）、受众（aud）、过期时间（exp）等Claims，不能直接信任令牌内容。
• 状态同步问题：自定义AuthenticationStateProvider需确保令牌过期、刷新后能及时更新认证状态，避免前端展示无效的授权状态。
• 授权逻辑一致性：自定义AuthorizeView的规则必须和内部服务的权限模型对齐，且前端授权仅做界面控制，核心权限校验必须由后端API完成。

为什么AddOidcAuthentication直接使用不可行？ #

Blazor WASM默认仅支持注册一个主AuthenticationStateProvider，同时调用AddMsalAuthentication和AddOidcAuthentication会导致服务注册冲突。但可以通过多Scheme认证的方式解决：

多Scheme认证实现方案 #

在Program.cs中为两个认证提供商指定不同的Scheme，复用官方认证组件的安全逻辑：

// 注册Entra（Azure AD）认证，使用默认Scheme
builder.Services.AddMsalAuthentication(options =>
{
    builder.Configuration.Bind("AzureAd", options.ProviderOptions.Authentication);
    options.ProviderOptions.DefaultAccessTokenScopes.Add("api://your-entra-api-scope");
});

// 注册内部OIDC认证，指定自定义Scheme
builder.Services.AddOidcAuthentication("InternalOidcScheme", options =>
{
    builder.Configuration.Bind("InternalOidc", options.ProviderOptions);
    // 配置内部OIDC的客户端ID、授权端点、令牌端点等信息
});

然后自定义一个CompositeAuthenticationStateProvider，继承AuthenticationStateProvider，根据当前路由或用户操作切换使用对应的认证状态：

public class CompositeAuthenticationStateProvider : AuthenticationStateProvider
{
    private readonly MsalAuthenticationStateProvider _msalProvider;
    private readonly OidcAuthenticationStateProvider _internalOidcProvider;
    private string _currentScheme = "oidc"; // 默认使用Entra认证

    public CompositeAuthenticationStateProvider(
        ILoggerFactory loggerFactory,
        HttpClient httpClient,
        IOptions<RemoteAuthenticationOptions<MsalProviderOptions>> msalOptions,
        IOptions<RemoteAuthenticationOptions<OidcProviderOptions>> internalOidcOptions)
    {
        _msalProvider = new MsalAuthenticationStateProvider(loggerFactory, httpClient, msalOptions);
        _internalOidcProvider = new OidcAuthenticationStateProvider(loggerFactory, httpClient, internalOidcOptions);
    }

    public void SwitchToInternalOidc()
    {
        _currentScheme = "InternalOidcScheme";
        NotifyAuthenticationStateChanged(GetAuthenticationStateAsync());
    }

    public void SwitchToEntra()
    {
        _currentScheme = "oidc";
        NotifyAuthenticationStateChanged(GetAuthenticationStateAsync());
    }

    public override async Task<AuthenticationState> GetAuthenticationStateAsync()
    {
        if (_currentScheme == "InternalOidcScheme")
        {
            return await _internalOidcProvider.GetAuthenticationStateAsync();
        }
        return await _msalProvider.GetAuthenticationStateAsync();
    }
}

最后将自定义的CompositeAuthenticationStateProvider注册为服务：

builder.Services.AddScoped<AuthenticationStateProvider, CompositeAuthenticationStateProvider>();

这种方案复用了官方组件的成熟安全逻辑，避免自定义实现带来的漏洞，同时支持双认证切换。

更推荐的令牌代理模式 #

如果内部服务允许，更安全的方式是通过后端API代理令牌请求：

1. 前端仅维护Entra的认证会话，用Entra令牌调用自己的后端API。
2. 后端用Entra令牌向内部OIDC提供商换取内部服务的访问令牌。
3. 后端直接调用内部API并返回结果给前端，或者将内部令牌加密后返回给前端（需控制令牌有效期和存储安全）。

这种模式的优势：

• 前端无需暴露内部OIDC的客户端密钥等敏感信息。
• 减少前端认证逻辑复杂度，避免双认证状态同步问题。
• 后端统一处理令牌刷新、权限校验，安全可控性更高。

不推荐单独搭建Blazor WASM管理认证 #

该方案属于过度设计，会增加部署维护成本，且跨应用的会话同步、令牌共享会带来额外的安全风险和复杂度，完全没必要。

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