Authentication 解决“你是谁”，Authorization 解决“你能做什么”；ASP.NET Core 中 UseAuthentication() 必须在 UseAuthorization() 之前，否则 IsAuthenticated 恒为 false；认证解析 Cookie 或 JWT 构建 ClaimsPrincipal，授权基于策略检查 Claims，失败返回 403。
Authentication 是登录验证，Authorization 是权限检查
Authentication 解决“你是谁”，即用户身份是否合法；Authorization 解决“你能做什么”，即该身份是否有权访问某个资源。在 ASP.NET Core 中，二者是两个独立中间件，顺序不能颠倒：app.UseAuthentication() 必须在 app.UseAuthorization() 之前调用，否则 User.Identity.IsAuthenticated 始终为 false，授权逻辑会直接拒绝所有请求。
Authentication 流程：从 Cookie 或 Token 到 ClaimsPrincipal
ASP.NET Core 的认证中间件不负责登录逻辑本身，只负责解析已建立的凭据并构造 ClaimsPrincipal。常见场景：
- 使用
CookieAuthenticationDefaults.AuthenticationScheme：浏览器发来.AspNetCore.CookiesCookie，中间件解密、反序列化出ClaimsIdentity，填充到HttpContext.User - 使用
JwtBearerDefaults.AuthenticationScheme：从Authorization: Bearer xxx提取 JWT，验证签名和有效期，映射为ClaimsPrincipal - 若认证失败（如 token 过期、cookie 被篡改），
HttpContext.User.Identity.IsAuthenticated为false，但请求仍会继续往下走——授权中间件此时通常会拒绝访问
Authorization 流程：基于策略（Policy）匹配 Claims
授权发生在认证之后，核心是 IAuthorizationService 对 HttpContext.User 执行策略评估。关键点：
-
[Authorize]特性默认触发DefaultPolicy，该策略要求用户已通过认证（即IsAuthenticated == true） - 自定义策略需在
Program.cs中注册，例如options.AddPolicy("AdminOnly", p => p.RequireRole("Admin"))，背后实际检查的是ClaimsPrincipal中role类型的 Claim 值 - 策略可组合多个要求（
IAuthorizationRequirement），比如同时校验角色 + 自定义声明（如tenant_id）+ 时间窗口 - 注意：授权失败时返回
403 Forbidden（而非401 Unauthorized），因为 401 仅用于认证失败场景
容易混淆的坑：401 和 403 的触发时机、User.Identity 空值问题
开发中常见误判：
- 控制器方法加了
[Authorize]却始终跳转到登录页或返回 401——大概率是漏掉了app.UseAuthentication()，或认证方案未正确配置（如 JWT 的TokenValidationParameters缺少ValidateIssuerSigningKey = true） -
HttpContext.User在中间件里为null或Identity.IsAuthenticated == false，但在 Action 里却正常——说明你把认证逻辑写在了UseAuthentication()之后的中间件里，违反了执行顺序 - 用
RequireClaim("scope", "api.read")却不生效——检查 JWT payload 是否真有scope字段，且其值是字符串数组还是空格分隔字符串（ASP.NET Core 默认按空格切分）
最常被忽略的是：认证与授权的扩展点完全不同。要改登录流程，看 IAuthenticationHandler；要加动态权限规则，得实现 IAuthorizationHandler，而不是试图在认证阶段塞授权逻辑。
