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 做第三方认证
适合企业级应用，省去自己实现账号密码逻辑：
