Blazor 怎么实现用户登录认证

Blazor登录认证分Blazor Server（cookie会话）和Blazor WebAssembly（JWT令牌）两种模式：前者复用ASP.net Core Cookie认证，后者依赖localStorage存JWT并配置httpClient自动携带Bearer头，企业级应用可集成azure AD或IdentityServer实现OIDC。

Blazor 实现用户登录认证，核心是区分运行模型：服务端（Blazor Server）和客户端（Blazor WebAssembly），两者认证机制差异明显。服务端靠服务端会话（如 Cookie）维持状态；WebAssembly 则必须依赖前端存储（如 localStorage）+ 后端颁发的令牌（如 JWT），全程无服务端 session。

服务端 Blazor 用 Cookie 认证最直接

它复用 ASP.NET Core 的传统身份验证体系，流程简洁可靠：

• 用户提交账号密码，后端验证通过后调用 HttpContext.SignInasync()，自动写入加密 Cookie
• 后续每次请求，浏览器自动携带该 Cookie，服务端自动解析并建立 ClaimsPrincipal
• 在 app.razor 中用 CascadingAuthenticationState 包裹整个应用，子组件即可通过 AuthenticationStateProvider 获取登录状态
• 受保护页面用 [Authorize] 特性或 AuthorizeRouteView 组件拦截未登录访问

WebAssembly 用 JWT Token 是主流做法

因为浏览器沙箱限制，无法共享服务端 Cookie，必须由前端主动管理令牌：

• 登录时调用后端 API（如 /api/auth/login），传用户名密码，成功返回 JWT 字符串
• 前端将 token 存入 localStorage 或 sessionStorage（注意 xss 风险）
• 配置 HttpClient 默认在请求头加 Authorization: Bearer {token}
• 自定义 AuthenticationStateProvider，在 GetAuthenticationStateAsync() 中读取本地 token、解析 claims 并构造 ClaimsPrincipal
• 退出时清空本地 token 即可，无需服务端干预

用 Azure AD 或 IdentityServer 做第三方认证

适合企业级应用，省去自己实现账号密码逻辑：

• Blazor WebAssembly 可集成 microsoft.Identity.Web，一行代码启用 Microsoft 登录
• 配置 OIDC 参数（Authority、ClientId、Scopes），点击登录自动跳转到 Azure AD 授权页
• 回调地址接收 code，后台自动换 token 并持久化，前端拿到用户信息后进入主应用
• 服务端 Blazor 同样支持，只需在 Startup/Program.cs 中注册 AddMicrosoftIdentityWebApp 服务

关键细节别忽略

无论哪种方式，这几个点直接影响安全与体验：

• Token 过期处理：WebAssembly 要监听 401 响应，触发重新登录或静默刷新（需 identity provider 支持 refresh token）
• 路由保护：不用只靠 [Authorize]，配合 Authorized 和 NotAuthorized 组件做条件渲染更友好
• 敏感操作二次确认：如修改密码、删除账户，建议额外校验当前 session 有效性或要求输入密码
• https 强制启用：JWT 和 Cookie 都不能走明文 HTTP，否则令牌极易被劫持

基本上就这些。选哪种方式，主要看部署模型和安全要求——内部管理系统常用 Cookie；面向公网的 SaaS 产品倾向 JWT 或 OIDC。