如何在Angular + ASP.NET Core中保障JWT认证的安全性？

嘿，针对你这套Angular 5 + ASP.NET Core的JWT认证方案，我整理了几个生产环境中必备的安全加固点，都是经过实践验证的实用技巧：

1. 密钥与签名算法加固 #

• 避免硬编码密钥：你当前从配置文件读取密钥的方式没问题，但要确保这个密钥绝不提交到代码仓库，建议用系统环境变量、加密的配置文件或者专用的密钥管理工具存储。另外，密钥长度要足够：如果使用HS256对称算法，密钥至少32字节（256位），太短的密钥容易被暴力破解。
• 优先使用非对称加密算法：HS256是对称加密，一旦密钥泄露，攻击者就能伪造任意Token。换成RS256/RSA512这类非对称算法会更安全——服务端用私钥签名Token，用公钥验证，私钥严格保密，公钥可以安全地暴露给客户端。示例配置如下：

// 替换对称密钥为RSA密钥
var rsa = RSA.Create();
rsa.ImportFromPem(appSettings.PrivateKeyPem); // 从配置读取私钥
x.TokenValidationParameters = new TokenValidationParameters
{
    ValidateIssuerSigningKey = true,
    IssuerSigningKey = new RsaSecurityKey(rsa),
    // 其他验证参数...
};

2. 完善Token验证规则 #

你的代码里已经初始化了JwtBearer认证，但要补充完整的Token验证参数，避免绕过安全检查：

.AddJwtBearer(x =>
{
    x.RequireHttpsMetadata = true; // 生产环境强制HTTPS传输
    x.SaveToken = true;
    x.TokenValidationParameters = new TokenValidationParameters
    {
        ValidateIssuerSigningKey = true,
        IssuerSigningKey = new SymmetricSecurityKey(key),
        ValidateIssuer = true,
        ValidIssuer = "https://your-api-domain.com", // 明确设置签发者
        ValidateAudience = true,
        ValidAudience = "https://your-angular-app.com", // 明确设置受众
        ValidateLifetime = true,
        ClockSkew = TimeSpan.Zero, // 关闭时钟偏移容忍，过期Token立即失效
        RequireExpirationTime = true // 强制Token包含过期时间
    };
});

3. 控制Token生命周期与刷新机制 #

• 缩短Access Token有效期：把Access Token的有效期设为15-30分钟，避免Token被盗用后长时间有效。
• 使用HttpOnly Cookie存储Refresh Token：Refresh Token用于获取新的Access Token，必须存在HttpOnly、Secure、SameSite=Strict的Cookie中，防止XSS攻击窃取。Angular端通过内存存储Access Token，不要用localStorage/sessionStorage。

4. 传输与存储安全 #

• 强制HTTPS传输：JWT的Payload是Base64编码的明文，必须用HTTPS加密传输，防止Token被中间人窃听。
• 不要在Payload中存敏感数据：虽然JWT有签名，但Payload可以被轻松解码，绝对不要把密码、用户隐私等敏感信息放在里面。

5. 防御XSS与CSRF攻击 #

• 启用ASP.NET Core的CSRF保护：如果用Cookie存储Refresh Token，必须启用CSRF防护，Angular会自动处理XSRF令牌的传递，只需在API端配置：

services.AddAntiforgery(options =>
{
    options.HeaderName = "X-XSRF-TOKEN";
});

• 依赖Angular内置XSS防护：确保Angular应用开启了默认的XSS防护，避免用户输入的恶意脚本被执行。

6. 实现Token撤销机制 #

JWT本身是无状态的，无法主动撤销，所以需要额外实现黑名单机制：

• 用Redis或内存缓存存储失效的Token（比如用户注销、密码修改、权限变更时），并设置和Token有效期一致的过期时间。
• 在JWT验证环节，先检查Token是否在黑名单中，再进行后续验证。

7. 权限细粒度控制 #

不要仅依赖JWT的存在就开放接口权限：

• 使用[Authorize(Roles="Admin")]或自定义策略，验证用户的角色和权限是否匹配接口要求。
• 服务端每次处理请求时，重新校验用户的权限状态，避免依赖JWT中的静态权限信息。

内容的提问来源于stack exchange，提问作者mrapi