Blazor WebAssembly托管应用：服务端Session存JWT方案是否可行安全？

方案是否合理？ #

• 这个方案可行但不算最优。其实Blazor WASM客户端完全能直接访问浏览器的localStorage/sessionStorage——你可以通过注入IJSRuntime做JS互操作，在自定义AuthenticationStateProvider里读写令牌。不过用服务端Session存令牌也没问题，本质是把原本客户端存的令牌移到了服务端，靠Session Cookie关联会话，这种模式更偏向传统服务器端会话认证，虽然背离了JWT无状态的设计初衷，但对于托管式Blazor应用来说，完全兼容，如果你更看重服务端对会话的管控能力，这个方案是合理的。

生产环境能不能正常运行？ #

• 可以正常跑，但要注意几个关键配置：
  • 别用内存缓存存Session：生产环境必须配分布式缓存（比如Redis），不然服务器重启或者加节点的时候，会话会丢，用户直接登出。
  • 会话超时和JWT过期要对齐：要么让Session超时时间和JWT的过期时间一致，要么做会话续期逻辑，避免用户还在操作就突然失效。
  • 性能影响不大：每次请求从服务端缓存读令牌，只要缓存够高效，这点开销基本可以忽略。

安全性如何？ #

• 安全性取决于你的配置细节：
  • 必须把Session Cookie的安全属性拉满：开启HttpOnly（防止XSS窃取Cookie）、Secure（只在HTTPS下传输）、SameSite=Strict（防CSRF），配置代码大概是这样：

    builder.Services.Configure<CookiePolicyOptions>(options =>
    {
        options.MinimumSameSitePolicy = SameSiteMode.Strict;
        options.HttpOnly = HttpOnlyPolicy.Always;
        options.Secure = CookieSecurePolicy.Always;
    });
    

  • 服务端缓存要加密：不管用Redis还是其他分布式缓存，都要开启加密，防止令牌被缓存泄露。
  • 对比客户端存储的优劣：服务端存令牌的好处是令牌不会暴露在浏览器里，XSS偷不到；但如果Session Cookie被劫持（比如CSRF成功），攻击者还是能冒充用户——不过只要Cookie配置到位，这种风险能降到很低。

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