JWT过期处理不再难：ASP.NET Core中实现滑动过期的3步法

原创 于 2025-11-18 17:37:51 发布 · 392 阅读 · 4 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

第一章：JWT过期机制的核心原理

JSON Web Token（JWT）是一种开放标准（RFC 7519），用于在网络应用环境间安全地传递声明。其中，过期机制是保障令牌安全性的重要组成部分，通过设置有效时间窗口防止令牌被长期滥用。

令牌中的时间相关声明

JWT 的载荷（Payload）部分包含多个标准字段，与过期机制密切相关的主要有：
  • exp (Expiration Time)：令牌的过期时间戳，单位为秒。在此时间之后，令牌应被视为无效。
  • iat (Issued At)：令牌签发时间，用于判断令牌是否过早使用。
  • nbf (Not Before)：令牌生效时间，在此时间之前不应被接受处理。
这些字段由服务端在生成 JWT 时写入，并在每次验证时进行校验。

服务端验证逻辑实现

以下是一个使用 Go 语言解析并验证 JWT 过期时间的示例： 
// 解析 JWT 并验证签名和过期时间
token, err := jwt.Parse(tokenString, func(token *jwt.Token) (interface{}, error) {
    return []byte("your-secret-key"), nil // 签名密钥
})

if err != nil {
    log.Fatal("Token 解析失败或已过期")
}

// 验证 token 是否有效且未过期
if claims, ok := token.Claims.(jwt.MapClaims); ok && token.Valid {
    exp := int64(claims["exp"].(float64))
    now := time.Now().Unix()
    
    if now > exp {
        log.Fatal("Token 已过期")
    }
} else {
    log.Fatal("Token 无效")
}
上述代码首先解析传入的令牌字符串，然后提取 exp 字段并与当前时间对比，确保令牌在有效期内。

典型过期策略对比

策略类型说明适用场景
固定过期时间所有令牌统一设置相同有效期，如 1 小时普通用户会话
动态过期时间根据用户角色或行为动态调整过期时间敏感操作、管理员账户
滑动过期（Refresh Token）结合短期访问令牌与长期刷新令牌移动端、长时间登录需求

第二章：ASP.NET Core中JWT认证的配置与实现

2.1 JWT认证的基本流程与Token结构解析

JWT（JSON Web Token）是一种基于JSON的开放标准（RFC 7519），用于在各方之间安全地传输信息。其认证流程始于用户提交凭据，服务端验证后生成JWT并返回客户端，后续请求通过携带该Token完成身份校验。
JWT的基本结构
一个JWT由三部分组成：头部（Header）、载荷（Payload）和签名（Signature），以点号分隔。例如： 

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ
.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
- 第一部分是Header，包含算法与类型； - 第二部分为Payload，携带声明信息； - 第三部分Signature由前两部分加密生成，确保完整性。
典型应用场景中的Token构成
字段名说明
sub主题，通常为用户唯一标识
exp过期时间戳
iat签发时间

2.2 在ASP.NET Core中配置JWT Bearer认证服务

在ASP.NET Core中启用JWT Bearer认证，需在服务注册阶段配置认证方案与JWT参数。
注册认证服务
在Program.cs中调用AddAuthentication与AddJwtBearer方法： 
builder.Services.AddAuthentication(options =>
{
    options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
    options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
})
.AddJwtBearer(options =>
{
    options.TokenValidationParameters = new TokenValidationParameters
    {
        ValidateIssuer = true,
        ValidateAudience = true,
        ValidateLifetime = true,
        ValidateIssuerSigningKey = true,
        ValidIssuer = builder.Configuration["Jwt:Issuer"],
        ValidAudience = builder.Configuration["Jwt:Audience"],
        IssuerSigningKey = new SymmetricSecurityKey(
            Encoding.UTF8.GetBytes(builder.Configuration["Jwt:Key"]))
    };
});
上述代码中，TokenValidationParameters用于定义令牌校验规则。其中：
  • ValidateIssuer：验证签发者是否匹配
  • ValidateAudience：验证受众是否合法
  • IssuerSigningKey：用于解密签名的密钥，应从配置安全读取
同时需确保调用UseAuthentication和UseAuthorization中间件以激活认证流程。

2.3 生成包含合理过期时间的JWT令牌

在构建安全的身份认证机制时，为JWT设置合理的过期时间至关重要。过短影响用户体验，过长则增加安全风险。
JWT过期时间的作用
过期时间（exp）是JWT标准声明中的关键字段，用于指示令牌的有效期限。服务器在验证时会自动拒绝已过期的令牌。
代码实现示例

claims := jwt.MapClaims{
    "user_id": 12345,
    "exp":     time.Now().Add(24 * time.Hour).Unix(), // 24小时后过期
}
token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)
signedToken, _ := token.SignedString([]byte("secret-key"))
上述Go代码使用jwt库生成包含24小时有效期的令牌。exp字段以Unix时间戳形式存储，确保跨系统兼容性。
常见过期策略对比
场景建议过期时间说明
Web登录8-24小时平衡安全与用户体验
API调用1-5分钟高频率、短周期操作
刷新令牌7-30天需配合短期访问令牌使用

2.4 验证Token过期行为并捕获相关异常

在JWT认证机制中，Token过期是常见的安全控制手段。服务端需主动识别已过期的Token，并返回明确的异常信息。
异常捕获逻辑实现
func ParseToken(tokenString string) (*jwt.Token, error) {
    token, err := jwt.Parse(tokenString, func(token *jwt.Token) (interface{}, error) {
        return jwtKey, nil
    })
    if err != nil {
        if ve, ok := err.(*jwt.ValidationError); ok {
            if ve.Errors&jwt.ValidationErrorExpired != 0 {
                return nil, fmt.Errorf("token已过期")
            }
        }
        return nil, fmt.Errorf("无效token")
    }
    return token, nil
}
该函数解析Token并判断错误类型，通过jwt.ValidationErrorExpired标识位确认是否因过期导致验证失败。
常见过期响应场景
  • 客户端携带过期Token访问受保护接口
  • 服务端返回401状态码并附带"Token expired"提示
  • 前端据此触发重新登录流程

2.5 使用Postman测试JWT认证接口的实效性

在开发基于Token的身份验证系统时，确保JWT的有效性和过期机制正确至关重要。Postman作为主流API测试工具，可直观模拟请求流程，验证认证逻辑。
配置Authorization头
发送请求前，需在Headers中设置： 
Authorization: Bearer <your-jwt-token>
其中Bearer为认证方案类型，<your-jwt-token>为登录接口返回的JWT字符串。
测试场景验证
  • 有效Token：获取受保护资源，状态码应为200
  • 过期Token：服务器应返回401 Unauthorized
  • 无效签名：拒绝访问并返回401
响应数据校验示例
测试条件HTTP状态码响应体说明
Token有效200返回目标资源数据
Token过期401{ "error": "Token expired" }

第三章：滑动过期策略的设计与应用场景

3.1 滑动过期的概念及其在Web应用中的价值

滑动过期（Sliding Expiration）是一种缓存或会话管理机制，每当资源被访问时，其有效期即被刷新。这种机制确保频繁使用的数据保持活跃，避免因固定过期时间导致的不必要重建。
核心工作原理
以用户会话为例，若设置滑动过期时间为30分钟，则每次请求都会重置倒计时。相比固定过期，显著提升用户体验。
典型应用场景
  • Web用户登录会话维持
  • 高频访问的API响应缓存
  • 临时令牌（如CSRF Token）生命周期管理
http.SetCookie(w, &http.Cookie{
    Name:    "session_id",
    Value:   sessionId,
    Expires: time.Now().Add(30 * time.Minute), // 初始过期
})
// 每次请求更新过期时间
cookie.Expires = time.Now().Add(30 * time.Minute)
上述Go代码展示了如何在中间件中实现滑动逻辑：每次请求更新Cookie的过期时间，从而延长有效周期。参数Expires动态重置是关键，确保活跃会话始终有效。

3.2 对比固定过期与滑动过期的安全性与用户体验

安全机制差异分析
固定过期策略在令牌生成时设定绝对失效时间，即使频繁使用也会准时失效，适合高安全场景。滑动过期则每次访问都会刷新过期时间，提升用户体验，但可能延长恶意令牌的有效期。
用户体验对比
  • 固定过期：用户需频繁重新登录，安全性高但体验较差；
  • 滑动过期：持续活跃可保持登录状态，体验更流畅，但需防范会话劫持。
// 滑动过期逻辑示例
if time.Since(lastAccess) < slidingWindow {
    token.ExpiresAt = time.Now().Add(30 * time.Minute) // 延长过期时间
}
该代码在用户访问时判断是否在滑动窗口内，若是则延长令牌有效期，实现“自动续签”。需配合频率限制防止滥用。

3.3 基于用户活动判断的Token刷新时机设计

在现代Web应用中，静态的Token过期策略易导致用户体验中断。通过监听用户行为动态调整刷新时机，可实现安全与体验的平衡。
用户活动检测机制
通过监听鼠标移动、键盘输入等事件判断活跃状态，仅在用户操作期间触发Token刷新： 
document.addEventListener('mousemove', handleUserActivity);
document.addEventListener('keypress', handleUserActivity);

function handleUserActivity() {
  if (!isTokenRefreshPending && isTokenNearExpiry()) {
    refreshToken();
  }
}
上述代码注册基础事件监听器，当检测到用户活动且Token即将过期时发起刷新请求，避免静默过期。
刷新策略决策表
用户状态Token剩余时间是否刷新
活跃< 5分钟是
非活跃任意否

第四章：实现滑动过期的三步法实战

4.1 第一步：拦截请求并检测Token剩余有效期

在实现Token自动刷新机制时，首要步骤是通过HTTP拦截器捕获每个传出请求，并检查当前Token的剩余有效时间。
拦截器核心逻辑
axios.interceptors.request.use(async (config) => {
  const token = localStorage.getItem('access_token');
  if (token) {
    const decoded = jwtDecode(token);
    const currentTime = Date.now() / 1000;
    // 当剩余有效期少于30秒时触发刷新
    if (decoded.exp - currentTime < 30) {
      await refreshToken();
    }
    config.headers.Authorization = `Bearer ${localStorage.getItem('access_token')}`;
  }
  return config;
});
上述代码利用JWT解码获取过期时间（exp），结合当前时间判断是否临近失效。阈值设定为30秒，预留网络延迟时间。
关键参数说明
  • exp：Token标准声明中的过期时间戳（秒）
  • currentTime：客户端当前时间（需同步系统时钟）
  • 30秒阈值：平衡安全性与请求频率的经验值

4.2 第二步：在Action过滤器中实现Token自动刷新逻辑

在ASP.NET Core中，Action过滤器是实现Token自动刷新的理想位置，能够在请求进入控制器前统一处理认证逻辑。
核心实现步骤
  • 检查请求携带的JWT Token是否即将过期
  • 若需刷新，则生成新的Token并写入响应头
  • 放行原请求，保障业务逻辑无缝执行
代码实现
public class TokenRefreshFilter : IActionFilter
{
    public void OnActionExecuting(ActionExecutingContext context)
    {
        var token = context.HttpContext.Request.Headers["Authorization"].ToString();
        if (IsExpiring(token))
        {
            var newToken = GenerateNewToken();
            context.HttpContext.Response.Headers["Refreshed-Token"] = newToken;
        }
    }

    private bool IsExpiring(string token) => /* 判断过期逻辑 */;
    private string GenerateNewToken() => /* 生成新Token */;
}
上述代码通过拦截每个Action调用，在请求预处理阶段完成Token状态判断与刷新。新Token通过自定义响应头返回，前端可据此更新本地存储的Token，实现无感续期。

4.3 第三步：返回新Token并确保客户端无缝更新

在身份认证流程中，服务端完成刷新验证后，需立即生成新的访问令牌（Access Token）并安全地传递给客户端。
响应结构设计
为保证兼容性与可扩展性，推荐使用标准 JSON 格式返回新 Token 及元信息： 
{
  "access_token": "eyJhbGciOiJIUzI1NiIs...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "def502..."
}
该响应包含四个关键字段：`access_token` 是新签发的令牌；`token_type` 指明认证类型；`expires_in` 表示有效期（秒）；`refresh_token` 可选，用于下一次刷新。
客户端无感更新策略
为实现无缝切换，前端应拦截过期错误，自动发起刷新请求，并将新 Token 注入后续请求头：
  • 检测到 401 响应时触发刷新流程
  • 更新本地存储中的 Token
  • 重试原失败请求

4.4 客户端配合处理刷新Token的最佳实践

在现代认证体系中，客户端需主动配合实现无感刷新Token机制，以提升用户体验与系统安全性。
请求拦截与Token状态判断
客户端应通过拦截器统一处理401响应，识别Token过期并触发刷新流程： 
axios.interceptors.response.use(
  response => response,
  async error => {
    if (error.response.status === 401 && !error.config._retry) {
      error.config._retry = true;
      await refreshToken(); // 调用刷新逻辑
      return axios(error.config);
    }
    return Promise.reject(error);
  }
);
上述代码通过标记 _retry 防止重复刷新，确保请求重试的原子性。
并发刷新控制
当多个请求同时收到401时，应避免多次调用刷新接口。可采用Promise锁机制：
  • 全局维护一个 refreshPromise 变量
  • 若存在进行中的刷新，则后续请求等待同一Promise结果
  • 刷新成功后清除Promise锁

第五章：总结与扩展思考

性能优化的实际路径
在高并发场景下，数据库连接池的配置直接影响系统吞吐量。以 Go 语言为例，合理设置最大空闲连接数和生命周期可避免连接泄漏： 
db.SetMaxOpenConns(100)
db.SetMaxIdleConns(10)
db.SetConnMaxLifetime(time.Hour)
结合 Prometheus 监控指标，可动态调整参数并观察 QPS 变化。
微服务架构中的容错设计
真实生产环境中，网络分区不可避免。使用熔断器模式能有效防止级联故障。以下是基于 Hystrix 的典型配置策略：
  • 设置请求超时为 500ms，避免长时间阻塞
  • 滑动窗口设为 10 秒，统计失败率
  • 当失败率超过 50%，触发熔断并进入半开状态试探恢复
  • 结合日志追踪（如 Jaeger）定位根因
某电商平台在大促期间通过该机制将订单服务可用性从 92% 提升至 99.97%。
技术选型的权衡矩阵
面对多种中间件选择，团队可通过量化评估做出决策。以下为消息队列选型参考：
候选系统吞吐量（万条/秒）延迟（ms）运维复杂度适用场景
Kafka100+<10高日志聚合、事件溯源
RabbitMQ5<100中任务调度、RPC 响应
图：基于 SLA 要求的技术决策流程——输入性能需求 → 评估成本与团队能力 → 沙箱验证 → 灰度上线
PixelFlow
关注
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值