Blazor身份验证提供程序的JWT令牌存储位置及自定义实现咨询

官方实现的存储逻辑 #

Blazor WASM官方身份验证方案（基于Microsoft.AspNetCore.Components.WebAssembly.Authentication包），底层是通过**JavaScript互操作调用浏览器的localStorage**来存储JWT令牌的，没有单独的可直接实例化的C#存储类。

官方的PersistentAccessTokenProvider是负责令牌持久化的核心类，它依赖IJSRuntime调用浏览器本地存储API完成令牌的读写。源码中可以看到，它会将令牌以键值对形式存在localStorage中，默认键名包含应用标识以避免冲突。

自定义实现的存储选项及取舍 #

针对自定义身份验证场景，常见存储方案各有优劣：

• localStorage：最常用方案，实现简单，令牌持久化（页面刷新、重启浏览器后仍存在）。缺点是易受XSS攻击——恶意脚本可直接读取localStorage中的令牌。如果能做好XSS防护（比如配置严格内容安全策略、校验用户输入），这是性价比最高的选择。
• sessionStorage：会话级存储，仅在当前浏览器会话有效，关闭窗口后令牌自动清除。XSS风险同样存在，但不会在本地持久化，适合对会话生命周期要求严格的场景。
• 内存存储：用单例C#类在内存中保存令牌，优点是完全隔离JS环境，XSS无法窃取；缺点是页面刷新后令牌丢失，用户需重新登录，体验较差，适合对安全性要求极高且能接受登录体验妥协的场景。
• HttpOnly Cookie：如果Blazor WASM托管在ASP.NET Core后端，可将JWT存入HttpOnly Cookie，由后端负责验证，前端无需直接操作令牌。这种方案XSS风险极低，但需处理跨域Cookie共享问题，适合前后端同域或配置正确CORS的场景。

自定义存储实现示例 #

以localStorage为例，通过JS互操作封装存储服务，再集成到AuthenticationStateProvider和IAccessTokenProvider中：

1. 编写JS存储脚本（wwwroot/auth.js） #

export function saveAuthToken(token) {
    localStorage.setItem("blazor_auth_token", token);
}

export function getAuthToken() {
    return localStorage.getItem("blazor_auth_token");
}

export function clearAuthToken() {
    localStorage.removeItem("blazor_auth_token");
}

2. 封装C#存储服务 #

public interface ITokenStorage
{
    Task SaveTokenAsync(string token);
    Task<string> GetTokenAsync();
    Task ClearTokenAsync();
}

public class LocalStorageTokenStorage : ITokenStorage
{
    private readonly IJSRuntime _jsRuntime;

    public LocalStorageTokenStorage(IJSRuntime jsRuntime)
    {
        _jsRuntime = jsRuntime;
    }

    public async Task SaveTokenAsync(string token)
    {
        await _jsRuntime.InvokeVoidAsync("saveAuthToken", token);
    }

    public async Task<string> GetTokenAsync()
    {
        return await _jsRuntime.InvokeAsync<string>("getAuthToken");
    }

    public async Task ClearTokenAsync()
    {
        await _jsRuntime.InvokeVoidAsync("clearAuthToken");
    }
}

3. 注册服务并集成到身份验证组件 #

在Program.cs中注册存储服务：

builder.Services.AddScoped<ITokenStorage, LocalStorageTokenStorage>();
builder.Services.AddScoped<IAccessTokenProvider, CustomAccessTokenProvider>();
builder.Services.AddScoped<AuthenticationStateProvider, CustomAuthStateProvider>();

在自定义IAccessTokenProvider中使用存储服务：

public class CustomAccessTokenProvider : IAccessTokenProvider
{
    private readonly ITokenStorage _tokenStorage;

    public CustomAccessTokenProvider(ITokenStorage tokenStorage)
    {
        _tokenStorage = tokenStorage;
    }

    public async ValueTask<AccessTokenResult> RequestAccessToken()
    {
        var token = await _tokenStorage.GetTokenAsync();
        if (string.IsNullOrWhiteSpace(token))
        {
            return AccessTokenResult.Failed(new AccessTokenRequestException("未找到有效令牌"));
        }

        // 可添加令牌过期校验逻辑
        var jwt = new JwtSecurityToken(token);
        if (jwt.ValidTo < DateTime.UtcNow)
        {
            return AccessTokenResult.Failed(new AccessTokenRequestException("令牌已过期"));
        }

        return AccessTokenResult.Success(new AccessToken(token));
    }

    // 实现接口其他方法（如RequestAccessToken(AccessTokenRequestOptions)）
}

安全建议 #

• 无论选择哪种存储方案，必须启用HTTPS，防止令牌在传输过程中被窃听。
• 若使用localStorage/sessionStorage，务必配置严格的内容安全策略（CSP），禁止内联脚本和未信任的脚本源，同时对所有用户输入做校验和转义，降低XSS风险。
• 为JWT设置合理的过期时间，并实现刷新令牌机制，减少令牌泄露后的影响范围。
• 敏感场景优先考虑HttpOnly Cookie或内存存储，结合自动登录（如记住我功能）优化用户体验。

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