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

是 否 +2 论坛币

k人 参与回答

经管之家送您一份

应届毕业生专属福利!

求职就业群

赵安豆老师微信：zhaoandou666

经管之家联合CDA

送您一个全额奖学金名额~ !

立即领取

感谢您参与论坛问题回答

经管之家送您两个论坛币！

+2 论坛币

第一章：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小时。	普通用户的会话管理
动态过期时间	依据用户角色或行为动态调整过期时间。	敏感操作及管理员账号
滑动过期（刷新令牌）	结合短期访问令牌和长期刷新令牌的策略。	移动设备、持续登录需求

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

2.1 JWT认证流程与Token结构分析

JWT（JSON Web Token）是一种基于JSON的开放标准（RFC 7519），用于在各方之间安全传输信息。认证流程开始于用户提交凭证，服务端验证后生成JWT并返回给客户端，后续请求通过携带此令牌完成身份验证。

JWT的基本构造

一个JWT由三个部分组成：头部（Header）、载荷（Payload）和签名（Signature），各部分以点号分隔。例如：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ
.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

• 头部：包含算法和类型信息。
• 载荷：包含声明信息。
• 签名：从前两部分加密生成，确保信息的完整性。

典型应用场景下的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设置合适的过期时间至关重要。过短会影响用户体验，过长则可能增加安全风险。

过期时间的重要性

过期时间（

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	返回未授权的消息。

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

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在没有用户干预的情况下过期。

刷新策略决策表

用户状态	Token剩余时间	是否刷新
活跃	< 5分钟	是
非活跃	任意	否

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

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

在构建Token自动刷新机制时，第一步是通过HTTP拦截器捕获每一个传出的请求，并检查当前Token的剩余有效时间。

拦截器的核心逻辑在于利用JWT解码获取过期时间（exp），并与当前时间对比，以确定Token是否接近失效。通常设定一个30秒的阈值，以考虑网络延迟。

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;
});

关键参数说明

• 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刷新机制，这不仅提高了用户体验，也增强了系统的安全性。

客户端应当通过拦截器统一处理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 的典型配置策略：

• 将请求超时时间设置为 500 毫秒，以避免长时间的阻塞。
• 滑动窗口设定为 10 秒，用于统计失败率。
• 当失败率超过 50% 时，触发熔断机制，并进入半开状态以试探恢复情况。

结合日志追踪工具（例如 Jaeger），可以帮助定位问题的根本原因。一家电商企业在大型促销活动期间，通过实施这一机制，将订单服务的可用性从 92% 提升到了 99.97%。

技术选型的权衡矩阵

面对众多的中间件选项，团队可以通过量化的评估来做出最佳决策。以下是一个消息队列选型的参考示例：

候选系统	吞吐量（万条/秒）	延迟（毫秒）	运维复杂度	适用场景
Kafka	100+	<10	高	日志聚合、事件溯源
RabbitMQ	5	<100	中	任务调度、RPC 响应

图：基于 SLA 要求的技术决策流程——输入性能需求 → 评估成本与团队能力 → 沙箱验证 → 灰度上线

扫码加我 拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

分享0 收藏0 回帖

关键词：core NET JWT cor Unauthorized