Echo框架怎么处理JWT过期问题-Golang-PHP中文网

echo框架不处理jwt过期逻辑，过期检查完全依赖jwt.parsewithclaims的选项配置；必须显式添加jwt.withexpirationrequired()等选项才能拦截过期token，否则仅签名正确即放行。

echo框架怎么处理jwt过期问题

直接说结论：Echo 框架本身不处理 JWT 过期逻辑，echo-jwt/v4 只做基础解析和签名验证；过期检查是否生效、容忍多少时钟偏差、是否允许 exp 字段缺失——全靠你配的 jwt.ParseWithClaims 参数和 KeyFunc 里的行为决定。

为什么 echo-jwt 默认“过期了也不报错”？

因为 echo-jwt 底层调用的是 golang-jwt/jwt/v5 的 ParseWithClaims，而这个函数默认不强制校验 exp 字段。如果你没显式传入 jwt.WithExpirationRequired() 或 jwt.WithValidTimeFunc，它就会安静地放过已过期的 token。

现象：请求带一个过期 2 小时的 token，echo-jwt 中间件仍放行，后续业务代码才发现用户身份异常
根本原因：token.Valid 返回 true，仅因签名正确 + 时间字段存在（哪怕 exp ）
正确做法：在 echo-jwt.Config 的 SigningMethod 和 KeyFunc 外，必须加 Options 数组

如何让过期 token 真正被拦截？

不是靠中间件开关，而是靠 jwt.ParseWithClaims 的选项组合。下面这段配置才是生产环境该写的：

Echo框架 5.1.0

Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。

下载

config := jwt.Config{
    KeyFunc: func(token *jwt.Token) (interface{}, error) {
        if _, ok := token.Method.(*jwt.SigningMethodHMAC); !ok {
            return nil, fmt.Errorf("unexpected signing method: %v", token.Header["alg"])
        }
        return jwtKey, nil
    },
    Options: []jwt.ParserOption{
        jwt.WithExpirationRequired(),     // 强制 exp 存在且未过期
        jwt.WithIssuedAt(),               // 强制校验 iat
        jwt.WithValidTimeFunc(func(t time.Time) bool {
            // 容忍服务端与客户端最多 ±5 秒时钟漂移
            return t.After(time.Now().Add(-5 * time.Second)) &&
                   t.Before(time.Now().Add(5 * time.Second))
        }),
    },
}
e.Use(jwt.WithConfig(config))

缺 WithExpirationRequired() → 过期 token 不报错
缺 WithValidTimeFunc → 服务器时间比客户端快 3 秒，刚签发就报 token is expired
WithIssuedAt() 能防重放，但必须配合 iat 字段签发，否则解析失败

过期后怎么让用户无感续期？

别指望 echo-jwt 帮你刷新 token——它连 refresh_token 都不认识。你要自己暴露一个 /auth/refresh 接口，规则必须严格：

该接口不能走 echo-jwt 中间件（否则过期 token 进不来），改用自定义 header 解析或 cookie 提取
从请求中拿到旧 refresh_token，查 DB/Redis 验证有效性、绑定关系、未被吊销
验证通过后，签发一对新 token：access_token（15 分钟）+ refresh_token（7 天），并更新存储中的旧 refresh token 状态
务必在响应头里设 HttpOnly + Secure Cookie 存 refresh token，别放 body 里

黑名单校验必须放在 echo-jwt 之后

很多人想在 echo-jwt 里塞黑名单逻辑，这是错的。它设计就是无状态的，强行改源码会破坏升级路径。

正确链路：echo-jwt → blacklistMiddleware → 业务 handler
黑名单中间件只做一件事：从 c.Get("user") 断言出 *jwt.Token，取 token.Claims.(jwt.MapClaims)["jti"]，查 Redis key revoked:{jti}
注意 fallback：如果没设 jti，可用 token.Raw 做哈希后查，但性能差、易冲突
Redis 写入要用 SET revoked:{jti} "" EX 900 NX，避免并发登出时漏写