在构建现代 Web 应用时身份验证和授权是保障系统安全的核心基石。对于 .NET 开发者尤其是使用 ASP.NET Core 框架的团队理解并正确实现这两套机制是项目从“能跑”到“能上线”的关键一步。身份验证解决的是“你是谁”的问题而授权则回答“你能做什么”。很多初学者容易混淆这两个概念或者虽然知道概念但在实际集成时面对 Cookie、JWT、OAuth、策略、声明、角色等众多选项常常感到无从下手配置了认证却发现授权不生效或者在生产环境遇到跨域、会话丢失、权限校验混乱等问题。本文将以 ASP.NET Core 为例系统性地拆解身份验证与授权的实现路径。我们将从最基础的概念和工作原理讲起然后通过一个完整的 Web API 项目演示如何从零开始集成基于 JWT Bearer Token 的认证和基于策略的授权。整个过程会涵盖环境准备、依赖配置、中间件注册、服务注入、控制器注解、策略定义等关键环节并解释每一步背后的设计意图。最后我们会深入探讨几个在生产环境中高频出现的坑点及其排查思路例如 Token 过期处理、跨域请求携带凭证、以及如何设计灵活的权限系统。无论你是刚开始接触 .NET Web 开发还是正在为现有项目重构安全模块这篇文章都能提供一条清晰、可复现的实践路径。1. 理解身份验证与授权的核心机制在动手写代码之前必须厘清身份验证和授权在 ASP.NET Core 中的运行机制。这有助于你在遇到问题时能准确判断是认证链路断了还是授权规则没匹配上。1.1 身份验证建立用户身份身份验证的目标是确认当前请求者的身份。在 Web 应用中这通常意味着服务器需要验证客户端提供的一组凭证例如用户名/密码、一个令牌或一个证书。ASP.NET Core 的身份验证系统是高度可插拔的其核心是身份验证方案和身份验证处理器。一个方案代表一种特定的验证方式例如Cookies、JwtBearer、OpenIdConnect等。每个方案都对应一个实现了IAuthenticationHandler的处理器。当 HTTP 请求到达时认证中间件会依次调用这些处理器尝试对请求进行认证。处理器会检查请求中是否包含自己能够识别的凭证如Authorization头中的 Bearer Token如果验证成功则会创建一个ClaimsPrincipal对象并将其设置为HttpContext.User。ClaimsPrincipal是用户身份的载体它包含一个或多个ClaimsIdentity而每个Identity又包含多个Claim。一个Claim就是一个关于用户的声明例如用户名、用户ID、角色、邮箱等。认证成功后这个包含用户声明的Principal对象就会在本次请求的后续管道中可用。1.2 授权校验访问权限授权发生在身份验证之后它决定了一个已认证的用户是否有权限执行特定操作。ASP.NET Core 的授权系统主要围绕策略展开。一个授权策略由一系列要求组成例如“要求用户拥有某个角色”或“要求用户满足某个自定义规则”。授权可以通过多种方式触发简单授权使用[Authorize]属性只要求用户通过认证。角色授权使用[Authorize(Roles Admin)]要求用户拥有指定角色。策略授权使用[Authorize(Policy PolicyName)]要求用户满足自定义策略。资源授权在代码中手动调用IAuthorizationService.AuthorizeAsync对特定资源进行精细化的权限判断。授权中间件会评估当前请求的HttpContext.User即认证阶段建立的ClaimsPrincipal是否满足控制器或 Action 上定义的授权要求。如果不满足则返回403 Forbidden状态码。1.3 中间件管道认证与授权的执行顺序这是最容易出错的地方之一。在Startup.cs或Program.cs中中间件的注册顺序至关重要。var app builder.Build(); // 顺序很重要 app.UseHttpsRedirection(); app.UseStaticFiles(); app.UseRouting(); // 1. 先注册认证中间件 app.UseAuthentication(); // 2. 再注册授权中间件 app.UseAuthorization(); app.MapControllers();UseAuthentication和UseAuthorization必须按此顺序注册并且必须在UseRouting之后、MapControllers或UseEndpoints之前。因为UseRouting负责将请求匹配到端点而认证和授权需要在端点执行前完成。如果顺序颠倒授权中间件将无法获取到已认证的用户信息。2. 环境准备与项目创建我们将创建一个使用 JWT 进行认证、并包含基础角色授权的 ASP.NET Core Web API 项目。2.1 开发环境要求确保你的开发环境满足以下要求组件版本要求说明.NET SDK6.0, 7.0, 8.0 或更高本文示例基于 .NET 8但核心概念适用于 6.0IDE / 编辑器Visual Studio 2022, VS Code, Rider任选其一具备 C# 开发环境即可测试工具Postman, curl 或 Swagger UI用于发送 HTTP 请求测试 API可以通过命令行检查 .NET 版本dotnet --list-sdks2.2 创建新项目打开终端或命令行创建一个新的 Web API 项目# 创建一个名为 AuthDemo 的 Web API 项目 dotnet new webapi -n AuthDemo -o AuthDemo cd AuthDemo # 运行项目确保基础框架正常 dotnet run项目创建后用你的 IDE 打开AuthDemo文件夹。你会看到标准的 ASP.NET Core Web API 项目结构包含Program.cs、WeatherForecastController.cs等文件。2.3 添加必要的 NuGet 包我们需要添加身份验证和授权相关的包。编辑项目文件AuthDemo.csproj或在包管理器控制台中执行命令。对于 .NET 8 项目Microsoft.AspNetCore.Authentication.JwtBearer包通常已隐式引用但为了清晰我们可以显式添加。同时为了生成 JWT我们还需要System.IdentityModel.Tokens.Jwt。Project SdkMicrosoft.NET.Sdk.Web PropertyGroup TargetFrameworknet8.0/TargetFramework !-- 其他属性 -- /PropertyGroup ItemGroup !-- 用于JWT认证 -- PackageReference IncludeMicrosoft.AspNetCore.Authentication.JwtBearer Version8.0.0 / !-- 用于生成和验证JWT令牌 -- PackageReference IncludeSystem.IdentityModel.Tokens.Jwt Version7.0.0 / /ItemGroup /Project然后在终端运行dotnet restore来还原包。3. 配置 JWT 身份验证我们将采用 JWT Bearer Token 作为认证方式。这种方式无状态适合 RESTful API 和前后端分离架构。3.1 在 appsettings.json 中配置 JWT 参数首先在appsettings.json或appsettings.Development.json中添加 JWT 的配置节。这些参数用于生成和验证 Token。{ Logging: { LogLevel: { Default: Information, Microsoft.AspNetCore: Warning } }, Jwt: { Issuer: AuthDemoServer, Audience: AuthDemoClient, Key: ThisIsMySuperSecretKeyWithAtLeast32Characters!!, // 生产环境务必使用强密钥并从安全位置读取 TokenExpiryInMinutes: 60 }, AllowedHosts: * }关键参数解释Issuer令牌的签发者。验证 Token 时会检查此声明是否匹配。Audience令牌的接收者。验证 Token 时会检查此声明是否匹配。Key用于签名和验证 Token 的密钥。这是安全关键示例中的密钥仅用于开发。在生产环境中必须使用足够长且复杂的密钥对于 HS256 算法建议至少 32 字节并通过环境变量、密钥管理服务等安全方式获取绝不能硬编码在配置文件中。TokenExpiryInMinutesToken 的有效期分钟。根据安全要求调整。3.2 在 Program.cs 中注册认证服务接下来在Program.cs中配置认证服务。我们将读取上一步的配置并添加 JWT Bearer 作为默认的认证方案。using Microsoft.AspNetCore.Authentication.JwtBearer; using Microsoft.IdentityModel.Tokens; using System.Text; var builder WebApplication.CreateBuilder(args); // 添加服务到容器中 builder.Services.AddControllers(); builder.Services.AddEndpointsApiExplorer(); builder.Services.AddSwaggerGen(); // 1. 从配置中读取JWT设置 var jwtSettings builder.Configuration.GetSection(Jwt); var key Encoding.ASCII.GetBytes(jwtSettings[Key]); // 2. 配置认证服务 builder.Services.AddAuthentication(options { // 设置默认的认证方案为 JwtBearer options.DefaultAuthenticateScheme JwtBearerDefaults.AuthenticationScheme; options.DefaultChallengeScheme JwtBearerDefaults.AuthenticationScheme; }) .AddJwtBearer(options { options.TokenValidationParameters new TokenValidationParameters { // 验证签发者 ValidateIssuer true, ValidIssuer jwtSettings[Issuer], // 验证接收者 ValidateAudience true, ValidAudience jwtSettings[Audience], // 验证签名密钥 ValidateIssuerSigningKey true, IssuerSigningKey new SymmetricSecurityKey(key), // 验证令牌有效期 ValidateLifetime true, // 允许的时钟偏差秒用于处理服务器间时间微小不同步 ClockSkew TimeSpan.Zero // 生产环境可设置为 TimeSpan.FromSeconds(30) }; // 可选自定义事件用于更精细的日志记录或处理特定错误 options.Events new JwtBearerEvents { OnAuthenticationFailed context { Console.WriteLine($认证失败: {context.Exception.Message}); return Task.CompletedTask; }, OnTokenValidated context { Console.WriteLine(Token验证成功); return Task.CompletedTask; } }; }); // 3. 配置授权服务为后续授权做准备 builder.Services.AddAuthorization(); var app builder.Build(); // ... 后续中间件配置代码详解AddAuthentication注册认证服务并设置默认方案。这告诉 ASP.NET Core 当需要认证时默认使用 JWT Bearer 方案。AddJwtBearer为 JWT Bearer 方案配置具体的验证参数TokenValidationParameters。这里我们启用了对签发者、接收者、签名和有效期的验证。ClockSkew这是一个重要的容错参数。它允许服务器时间和 Token 签发时间之间存在一定偏差。在分布式系统中服务器时钟可能不完全同步设置一个合理的ClockSkew如30秒可以避免因微小时间差导致的验证失败。在开发环境或对时间要求严格的场景可以设为TimeSpan.Zero。AddAuthorization注册授权服务。即使现在不定义策略也需要调用此方法。3.3 添加认证与授权中间件确保在Program.cs的app构建部分按正确顺序添加中间件。// 配置 HTTP 请求管道 if (app.Environment.IsDevelopment()) { app.UseSwagger(); app.UseSwaggerUI(); } app.UseHttpsRedirection(); // **关键顺序Routing - Authentication - Authorization - MapControllers** app.UseRouting(); app.UseAuthentication(); // 认证中间件 app.UseAuthorization(); // 授权中间件 app.MapControllers(); app.Run();4. 实现登录接口与 Token 生成现在我们需要一个端点来验证用户凭证如用户名密码并生成 JWT Token。4.1 创建用户模型和登录请求模型在项目根目录创建Models文件夹并添加以下类// Models/LoginRequest.cs namespace AuthDemo.Models; public class LoginRequest { public string Username { get; set; } string.Empty; public string Password { get; set; } string.Empty; }// Models/User.cs namespace AuthDemo.Models; public class User { public int Id { get; set; } public string Username { get; set; } string.Empty; public string PasswordHash { get; set; } string.Empty; // 实际项目中应存储哈希值而非明文 public string Role { get; set; } string.Empty; // 用户角色如 Admin, User }4.2 创建认证服务创建一个服务类来封装用户验证和 Token 生成的逻辑。在Services文件夹下创建IAuthService.cs和AuthService.cs。// Services/IAuthService.cs using AuthDemo.Models; namespace AuthDemo.Services; public interface IAuthService { Taskstring? AuthenticateAndGetToken(LoginRequest loginRequest); }// Services/AuthService.cs using System.IdentityModel.Tokens.Jwt; using System.Security.Claims; using System.Text; using AuthDemo.Models; using Microsoft.IdentityModel.Tokens; namespace AuthDemo.Services; public class AuthService : IAuthService { private readonly IConfiguration _configuration; // 模拟用户数据存储。实际项目中应查询数据库。 private readonly ListUser _mockUsers new() { new User { Id 1, Username admin, PasswordHash admin123, Role Admin }, // 明文密码仅为演示 new User { Id 2, Username user1, PasswordHash user123, Role User }, }; public AuthService(IConfiguration configuration) { _configuration configuration; } public Taskstring? AuthenticateAndGetToken(LoginRequest loginRequest) { // 1. 验证用户凭证此处为模拟验证 var user _mockUsers.SingleOrDefault(u u.Username loginRequest.Username u.PasswordHash loginRequest.Password); if (user null) { return Task.FromResultstring?(null); // 认证失败 } // 2. 生成JWT Token var tokenHandler new JwtSecurityTokenHandler(); var key Encoding.ASCII.GetBytes(_configuration[Jwt:Key]!); var tokenDescriptor new SecurityTokenDescriptor { Subject new ClaimsIdentity(new[] { new Claim(ClaimTypes.NameIdentifier, user.Id.ToString()), new Claim(ClaimTypes.Name, user.Username), new Claim(ClaimTypes.Role, user.Role) // 将角色作为声明加入Token // 可以添加更多自定义声明如部门、权限点等 }), Expires DateTime.UtcNow.AddMinutes(double.Parse(_configuration[Jwt:TokenExpiryInMinutes]!)), Issuer _configuration[Jwt:Issuer], Audience _configuration[Jwt:Audience], SigningCredentials new SigningCredentials(new SymmetricSecurityKey(key), SecurityAlgorithms.HmacSha256Signature) }; var token tokenHandler.CreateToken(tokenDescriptor); return Task.FromResultstring?(tokenHandler.WriteToken(token)); } }关键点说明密码存储示例中使用了明文密码这是极其危险的。实际项目中必须使用加盐哈希如 PBKDF2、BCrypt来存储密码哈希值并在验证时进行比对。声明Claims是构建用户身份的核心。我们添加了用户ID、用户名和角色声明。ClaimTypes.Role是一个预定义的类型便于后续进行角色授权。Token生成使用JwtSecurityTokenHandler和SecurityTokenDescriptor来构建 Token。签名算法选择了HmacSha256Signature对应 HS256它使用对称密钥。4.3 注册服务并创建 AuthController在Program.cs中注册IAuthServicebuilder.Services.AddScopedIAuthService, AuthService();然后创建Controllers/AuthController.csusing AuthDemo.Models; using AuthDemo.Services; using Microsoft.AspNetCore.Mvc; namespace AuthDemo.Controllers; [ApiController] [Route(api/[controller])] public class AuthController : ControllerBase { private readonly IAuthService _authService; public AuthController(IAuthService authService) { _authService authService; } [HttpPost(login)] public async TaskIActionResult Login([FromBody] LoginRequest request) { var token await _authService.AuthenticateAndGetToken(request); if (token null) { return Unauthorized(new { message 用户名或密码错误 }); } return Ok(new { token }); } }这个控制器提供了一个POST /api/auth/login端点接收用户名和密码调用认证服务成功则返回 JWT Token失败则返回 401。5. 应用授权保护 API 端点有了认证和 Token 生成能力我们现在来保护其他 API 端点。5.1 使用简单授权和角色授权修改自带的WeatherForecastController或创建一个新的ProtectedController。using Microsoft.AspNetCore.Authorization; using Microsoft.AspNetCore.Mvc; namespace AuthDemo.Controllers; [ApiController] [Route(api/[controller])] [Authorize] // 整个控制器需要认证 public class ProtectedController : ControllerBase { [HttpGet(public)] [AllowAnonymous] // 此端点允许匿名访问覆盖控制器的[Authorize] public IActionResult GetPublicData() { return Ok(new { message 这个数据对所有人可见。 }); } [HttpGet(user-data)] public IActionResult GetUserData() { // 可以通过 HttpContext.User 获取当前用户信息 var userName User.Identity?.Name; var userId User.FindFirst(ClaimTypes.NameIdentifier)?.Value; return Ok(new { message $你好{userName} (ID: {userId})这是你的数据。 }); } [HttpGet(admin-data)] [Authorize(Roles Admin)] // 此端点需要用户拥有“Admin”角色 public IActionResult GetAdminData() { return Ok(new { message 欢迎管理员。这是敏感的管理数据。 }); } [HttpGet(multi-roles)] [Authorize(Roles Admin,Manager)] // 用户只需拥有 Admin 或 Manager 角色之一即可 public IActionResult GetMultiRoleData() { return Ok(new { message 你拥有 Admin 或 Manager 权限。 }); } }授权属性详解[Authorize]应用于控制器类或 Action 方法表示该端点需要用户通过认证。未认证的请求将返回401 Unauthorized。[AllowAnonymous]应用于 Action 方法表示即使控制器要求认证此方法也允许匿名访问。它用于在受保护的控制器中开放个别公共接口。[Authorize(Roles RoleName)]在要求认证的基础上进一步要求用户必须属于指定的角色。多个角色用逗号分隔表示“或”的关系。5.2 创建并应用自定义授权策略角色授权有时不够灵活。我们可以定义更复杂的策略。在Program.cs的AddAuthorization部分进行配置。builder.Services.AddAuthorization(options { // 策略1要求用户年龄声明大于等于18岁 options.AddPolicy(AtLeast18, policy policy.RequireAssertion(context context.User.HasClaim(c c.Type Age int.TryParse(c.Value, out var age) age 18) )); // 策略2要求用户拥有特定权限声明例如“CanReadReport” options.AddPolicy(CanReadReport, policy policy.RequireClaim(Permission, CanReadReport)); // 策略3组合要求既是Admin角色又拥有特定权限 options.AddPolicy(AdminWithReportAccess, policy { policy.RequireRole(Admin); policy.RequireClaim(Permission, CanReadReport); }); });然后在控制器中使用自定义策略[HttpGet(adult-only)] [Authorize(Policy AtLeast18)] public IActionResult GetAdultOnlyData() { return Ok(new { message 此内容仅对成年人开放。 }); } [HttpGet(report)] [Authorize(Policy CanReadReport)] public IActionResult GetReport() { return Ok(new { message 这是报表数据。 }); }要使用这些策略需要在生成 Token 时添加对应的声明。修改AuthService中的 Token 生成部分模拟添加声明var claims new ListClaim { new Claim(ClaimTypes.NameIdentifier, user.Id.ToString()), new Claim(ClaimTypes.Name, user.Username), new Claim(ClaimTypes.Role, user.Role), // 添加自定义声明 new Claim(Age, 25), // 假设用户25岁 new Claim(Permission, CanReadReport), };6. 运行验证与测试现在让我们运行项目并测试整个流程。6.1 启动项目并获取 Token在终端运行dotnet run启动项目。使用 Postman、curl 或 Swagger UI如果启用测试。首先调用登录接口获取 TokenURL:POST https://localhost:PORT/api/auth/loginBody (JSON):{ username: admin, password: admin123 }成功响应:{ token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... }复制这个token值。6.2 测试受保护的端点使用获取到的 Token 访问需要认证或授权的接口。测试公共接口应成功:GET https://localhost:PORT/api/protected/public无需Authorization头应返回200 OK。测试需要认证的接口不带Token应失败:GET https://localhost:PORT/api/protected/user-data不设置Authorization头应返回401 Unauthorized。测试需要认证的接口带Token应成功:GET https://localhost:PORT/api/protected/user-data在请求头中添加Authorization: Bearer 你的Token应返回200 OK并看到欢迎信息。测试需要 Admin 角色的接口使用 user1 的Token应失败:先用user1/user123登录获取另一个 Token。GET https://localhost:PORT/api/protected/admin-data使用 user1 的 Token应返回403 Forbidden。使用 admin 的 Token应返回200 OK。测试自定义策略接口:使用 admin 的 Token其中包含了Age25和PermissionCanReadReport声明。GET https://localhost:PORT/api/protected/adult-only和GET https://localhost:PORT/api/protected/report都应返回200 OK。通过以上步骤你可以完整地验证认证和授权流程是否正常工作。7. 常见问题排查与解决方案在实际开发中你可能会遇到以下问题。这里提供排查思路。7.1 Token 相关错误问题现象可能原因排查步骤解决方案401 Unauthorized1. 请求未携带 Token。2. Token 格式错误如缺少 ‘Bearer’ 前缀。3. Token 已过期。4. Token 签名验证失败密钥不匹配。1. 检查请求头Authorization: Bearer token格式是否正确。2. 在 jwt.io 解码 Token检查exp字段是否过期。3. 对比签发和验证时使用的Issuer,Audience,Key是否完全一致。1. 确保客户端正确附加 Token。2. 重新登录获取新 Token。3. 检查服务器和客户端的 JWT 配置特别是密钥是否一致。403 Forbidden1. 用户认证成功但角色或权限不满足授权要求。1. 解码 Token检查role声明或自定义声明是否符合接口要求。2. 检查控制器或 Action 上的[Authorize(Roles...)]或[Authorize(Policy...)]属性。1. 为用户分配正确的角色或权限。2. 调整接口的授权要求。IDX10501: Signature validation failedToken 签名无效。通常是因为用于验证的密钥与签发时使用的密钥不同。1. 确认服务器重启后密钥未改变。2. 确认生产环境和开发环境配置未混淆。确保签发和验证使用相同的安全密钥。考虑使用非对称加密如 RSA或从集中式配置/密钥库获取密钥。7.2 配置与中间件顺序问题问题现象可能原因排查步骤解决方案认证/授权完全不生效1.UseAuthentication或UseAuthorization中间件未注册。2. 中间件顺序错误。1. 检查Program.cs中是否调用了app.UseAuthentication()和app.UseAuthorization()。2.重点检查顺序必须是UseRouting()-UseAuthentication()-UseAuthorization()-MapControllers()。按正确顺序注册中间件。Swagger UI 无法发送带Token的请求Swagger 未配置认证支持。1. 尝试用 Postman 测试如果 Postman 正常而 Swagger 不行则是 Swagger 配置问题。在Program.cs中配置 Swagger 支持 JWTcsharpbrbuilder.Services.AddSwaggerGen(c br{br // ... 其他配置br c.AddSecurityDefinition(Bearer, new OpenApiSecuritySchemebr {br Description JWT Authorization header,br Name Authorization,br In ParameterLocation.Header,br Type SecuritySchemeType.ApiKey,br Scheme Bearerbr });br c.AddSecurityRequirement(...);br});br7.3 跨域请求问题在前后端分离架构中前端从不同域名或端口访问 API 时需要配置 CORS。问题现象前端请求成功发送但浏览器控制台报 CORS 错误且后端可能收到OPTIONS预检请求。解决方案在Program.cs中配置 CORS 策略并允许携带凭证因为我们要发送 Authorization 头。// 在服务容器中配置CORS策略 builder.Services.AddCors(options { options.AddPolicy(AllowMyFrontend, builder { builder.WithOrigins(https://localhost:3000) // 你的前端地址 .AllowAnyMethod() .AllowAnyHeader() .AllowCredentials(); // 允许携带凭证如cookies, authorization headers }); }); // 在中间件管道中使用CORS顺序在UseRouting之后UseAuthentication/Authorization之前或之后均可但必须在UseEndpoints之前 app.UseCors(AllowMyFrontend);注意AllowCredentials()和WithOrigins(*)不能同时使用。必须指定明确的来源。8. 生产环境最佳实践与扩展方向将上述示例部署到生产环境前需要考虑以下关键点。8.1 安全加固清单密钥管理绝对禁止将密钥硬编码在appsettings.json或代码中。使用环境变量、Azure Key Vault、AWS Secrets Manager 或 HashiCorp Vault 等安全服务存储密钥。在Program.cs中通过Environment.GetEnvironmentVariable(JWT_KEY)等方式读取。密码存储使用强哈希算法如 ASP.NET Core Identity 中的PasswordHasher或BCrypt.Net处理用户密码。永远不要存储或传输明文密码。Token 安全设置合理的 Token 有效期如 15-60 分钟。对于更长的会话考虑使用刷新令牌机制。考虑使用非对称加密如 RS256代替对称加密HS256将私钥用于签发公钥用于验证更安全。在服务端维护一个令牌黑名单用于注销或使用更短的有效期来规避此问题。HTTPS生产环境必须全程使用 HTTPS防止 Token 在传输中被窃取。8.2 架构扩展建议集中式用户与权限管理将用户、角色、权限数据存储在数据库如 SQL Server, PostgreSQL中。使用 ASP.NET Core Identity 框架可以快速搭建这套体系它提供了用户管理、角色管理、外部登录等大量开箱即用的功能。基于声明的细粒度授权除了角色更多地使用自定义声明和策略来实现细粒度权限控制。例如可以为用户声明Permission列表然后定义策略如RequirePermission:EditArticle。策略提供程序对于复杂的、需要从数据库动态加载的授权规则可以实现IAuthorizationPolicyProvider来动态生成策略。资源授权对于“用户只能编辑自己的文章”这类需求简单角色或声明策略不够。需要在业务逻辑层使用IAuthorizationService进行资源级别的授权检查。集成外部认证如果需要支持第三方登录如 Google, GitHub, Microsoft可以使用AddOpenIdConnect或AddOAuth方案轻松集成。8.3 监控与日志在JwtBearerEvents中记录认证成功和失败的事件便于审计和排查问题。监控认证失败401和授权失败403的请求比例异常升高可能意味着攻击或配置错误。使用 Application Insights、Serilog 等工具结构化记录日志。通过遵循以上实践你可以在 .NET 项目中构建一个既安全又灵活的身份验证与授权系统。核心在于理解管道中间件的工作顺序、清晰区分认证与授权的职责、并利用好声明和策略这套强大的抽象机制。从最小可运行的例子开始逐步根据实际业务需求引入数据库、Identity框架和更复杂的授权逻辑是稳妥的演进路径。