在C#企业级应用里，网络安全和身份验证并不是上线前才考虑的点，而是贯穿需求、设计、编码和运维的整体工程。攻击者常利用弱口令、明文传输、越权接口来获取系统控制权，因此我们需要在框架层面建立可信身份体系，并在通信链路上消除窃听与篡改风险。
一、基于ASP.NET Core Identity的身份验证基础
ASP.NET Core Identity是官方提供的成员系统，它将用户、角色、声明等抽象为可持久化的实体，并使用加盐哈希算法保存密码。相比自己写MD5加密，Identity默认采用PBKDF2算法，能有效拖慢暴力破解速度。在新建Web应用时，可以通过模板直接引入Identity，也可以在现有项目中手动注册服务。
下面代码展示了在Program.cs中配置Identity并指定密码强度策略。注意AddEntityFrameworkStores会将用户数据映射到数据库上下文，而RequireDigit等选项能在注册阶段拦截弱密码，从源头减少被攻破的可能。
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddDbContext<AppDbContext>(opt =>
opt.UseSqlServer(builder.Configuration.GetConnectionString("Default")));
builder.Services.AddIdentity<ApplicationUser, IdentityRole>(options =>
{
options.Password.RequireDigit = true;
options.Password.RequiredLength = 10;
options.Password.RequireNonAlphanumeric = false;
options.User.RequireUniqueEmail = true;
})
.AddEntityFrameworkStores<AppDbContext>()
.AddDefaultTokenProviders();
builder.Services.AddControllersWithViews();
var app = builder.Build();
app.UseAuthentication();
app.UseAuthorization();
app.MapDefaultControllerRoute();
app.Run();
上述配置只是起点。在真实业务中，我们往往还需要开启双因素认证、账户锁定阈值等高级防护。Identity通过UserManager和SignInManager暴露了相应API，开发者可以在登录逻辑中判断锁定时间并提示用户，而不是仅返回模糊的登录失败。
另外，密码重置令牌应使用非对称或带有效期的随机令牌，避免被预测。AddDefaultTokenProviders已内置邮件和短信令牌生成器，配合HTTPS下的回调链接，可构建完整的自助找回流程，同时避免令牌在日志中明文打印。
二、传输层安全与HTTPS强制策略
即便后端验证再严密，若数据以明文HTTP传输，攻击者仍可在局域网或公共WiFi中抓包获取Cookie和令牌。因此C#服务必须重定向所有HTTP请求到HTTPS，并启用HSTS告知浏览器在指定时间内只允许加密连接。ASP.NET Core通过UseHttpsRedirection和UseHsts中间件实现这一点。
在开发环境可暂时关闭HSTS以免自签证书带来麻烦，但生产环境务必开启。以下片段演示了条件化注册，既保证本地调试顺畅，也确保发布后链路加密不被绕过。
if (!app.Environment.IsDevelopment())
{
app.UseHsts();
}
app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();
app.MapControllers();
除了重定向，还应检查TLS版本。老旧的TLS 1.0和1.1已被证明存在隐患，可在服务器或Kestrel配置中限定最低版本为TLS 1.2。对于内部服务间调用，建议使用双向证书认证，防止非法节点接入微服务网络。
前端页面中涉及表单提交时，务必将敏感字段放在具有autocomplete属性的受控输入内，并配合Content-Security-Policy响应头限制脚本来源，降低XSS导致令牌泄露的连锁风险。
三、JWT与无状态API鉴权
现代C#后端常采用前后端分离架构，传统的基于Cookie的会话在跨域和移动端场景下不够灵活。JSON Web Token（JWT）以声明形式携带用户身份，服务端通过签名验证完整性，无需集中存储会话。其缺点是令牌签发后到过期前均有效，因此应设置较短有效期并配合刷新令牌。
下面示例展示如何用Microsoft.AspNetCore.Authentication.JwtBearer包配置验证参数。Issuer和Audience用于防止令牌被其他系统冒用，而ClockSkew可容忍少量时间偏差，避免分布式环境时钟不同步造成误拒。
builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
.AddJwtBearer(options =>
{
options.TokenValidationParameters = new TokenValidationParameters
{
ValidateIssuer = true,
ValidIssuer = builder.Configuration["Jwt:Issuer"],
ValidateAudience = true,
ValidAudience = builder.Configuration["Jwt:Audience"],
ValidateLifetime = true,
IssuerSigningKey = new SymmetricSecurityKey(
Encoding.UTF8.GetBytes(builder.Configuration["Jwt:Key"])),
ClockSkew = TimeSpan.FromMinutes(2)
};
});
在控制器中，只需标注[Authorize]即可要求有效令牌。若需细粒度控制，可基于策略检查声明，例如要求用户的部门声明等于特定值才允许访问财务接口。这种声明式授权比在方法内写if判断更易于维护。
刷新令牌建议保存在服务器端的分布式缓存如Redis中，并绑定设备指纹。当检测到令牌在异地频繁刷新时，可主动吊销，从而把泄露影响控制在很短窗口内。
四、防御常见Web攻击的补充手段
CSRF攻击利用浏览器自动携带Cookie的特性伪造请求，虽然在JWT模式下影响减小，但混合Cookie认证时仍需防范。可在表单中生成防伪造令牌，并在Razor页面使用@Html.AntiForgeryToken()辅助方法，服务端通过AutoValidateAntiforgeryToken特性校验。
重放攻击则可通过在请求中加入单调递增序号或时间戳声明来缓解。下列代码展示了一个简单的中间件思路：在内存字典中记录最近有效时间戳，若收到过期或重复时间戳则拒绝，适用于对实时性要求高的交易接口。
public class ReplayGuardMiddleware
{
private readonly RequestDelegate _next;
private static readonly HashSet<long> _seen = new();
public ReplayGuardMiddleware(RequestDelegate next) => _next = next;
public async Task InvokeAsync(HttpContext context)
{
if (context.Request.Headers.TryGetValue("X-Timestamp", out var tsStr)
&& long.TryParse(tsStr, out var ts))
{
var now = DateTimeOffset.UtcNow.ToUnixTimeSeconds();
if (now - ts > 30 || !_seen.Add(ts))
{
context.Response.StatusCode = 401;
return;
}
}
await _next(context);
}
}
此外，所有外部输入都应在模型绑定阶段用数据注解如[Required]、[StringLength]进行约束，并在仓储层使用参数化查询，杜绝SQL注入。C#的EF Core默认参数化LINQ翻译，但若使用原生SQL务必通过FromSqlInterpolated传入变量。
日志系统也应脱敏，避免把身份证号或令牌写入明文文件。可用Serilog的销毁器或自定义ILogger过滤器，在输出前替换敏感字段，兼顾排查需要与合规要求。
五、总结与实践建议
处理C#中的网络安全与身份验证，核心是先明确威胁模型，再选用框架原生能力降低自研错误。Identity负责身份存储与生命周期，HTTPS与HSTS守护传输，JWT适应无状态分布，中间件补齐业务特有风险。团队应将安全配置纳入代码评审清单，并定期用自动化扫描工具验证暴露面。
当新功能涉及权限时，优先使用声明和策略而非硬编码角色字符串，这样在组织结构调整时只需改配置。只有把防护措施做成默认路径，才能让开发者在不增加认知负担的情况下写出更安全的系统。