“既要…又要…”的陷阱：深入剖析 JWT 与 Session 的“混合模式”认证 !

原创于 2025-08-02 19:22:43 发布 · 731 阅读

17 ·

CC 4.0 BY-SA版权

文章标签：

#jwt #session

产品资质管理系统专栏收录该内容

154 篇文章

订阅专栏

“既要…又要…”的陷阱：深入剖析 JWT 与 Session 的“混合模式”认证 ⚠️

嘿，各位后端开发者！👋 在构建用户认证系统时，我们常常面临选择：是采用经典的有状态 Session-Cookie 模式，还是拥抱现代的无状态 JWT (JSON Web Token) 模式？

但有时候，在项目迭代或技术选型不明确时，会出现一种奇特的“缝合怪”——JWT 与 Session 的混合认证模式。在这种模式下，系统一方面通过 JWT 进行身份验证，另一方面又在验证成功后，默默地创建或更新了一个服务器端的 Session。

这种“我全都要”的设计，看似两全其美，实则可能埋下了逻辑混乱、性能瓶颈和安全隐患的种子。今天，我们就结合一段真实的代码案例，深入剖-析这种混合模式的实现细节、它会引发的奇怪行为，以及为什么我们应该极力避免它。

🎯 案发现场：一段“暗藏玄机”的拦截器代码

让我们来看一段典型的混合模式认证拦截器 JwtAuthenticationInterceptor 的核心逻辑：

package com.productQualification.api.filter;

// ... imports ...
import com.productQualification.common.util.JwtUtils;
import org.springframework.web.servlet.HandlerInterceptor;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class JwtAuthenticationInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object object) throws Exception {
        // ... 检查 @PassToken 注解，跳过公共接口 ...

        // 1. 从请求头获取 Token
        String token = request.getHeader("token");
        if (token == null) {
            throw new TokenException("token 为空");
        }

        // 2. 解析并验证 Token (典型的无状态操作)
        String userId = JwtUtils.getAudience(token);
        JwtUtils.verifyToken(token, userId);
        
        // ... 将认证信息放入 SecurityContextHolder ...

        // 3. 【关键问题所在】根据 Token 信息查询数据库
        String type = JwtUtils.getClaimByName(token, "type").asString();
        if ("user".equals(type)) {
            User user = userService.findByOpenId(...);
            // 4. 将用户 ID 存入服务器端的 Session！(典型的有状态操作)
            request.getSession().setAttribute(Constants.USER_ID, user.getId());
        } else {
            Admin admin = adminCacheService.findById(...);
            // 同样，将管理员信息存入 Session
            request.getSession().setAttribute(Constants.ADMIN_ID, admin.getId());
        }

        return true; // 放行请求
    }
}

行为	所属模式	作用
从 Header 获取 Token	无状态 (Stateless)	接收客户端的身份凭证。
验证 Token 签名和有效期	无状态 (Stateless)	确认凭证的合法性，服务器不存储任何状态。
`request.getSession().setAttribute(...)`	有状态 (Stateful)	在服务器端创建或更新一个 Session，存储用户登录状态。

这段代码完美地展示了两种模式的“缝合”：它用无状态的方式验证了身份，却用有状态的方式维持了会话。

🤔 灵魂追问：`JSESSIONID` Cookie 是从哪里冒出来的？

你可能会问：“我的代码里只写了 JWT，从没碰过 Cookie，那个 JSESSIONID Cookie 是怎么来的？”

答案就藏在那行看似无害的代码里：request.getSession()。

request.getSession() 是一个“潘多拉魔盒”，一旦调用，就会自动触发完整的 Session-Cookie 机制。

它的内部工作流程是这样的：

检查“信物”：服务器首先检查收到的请求头里，有没有一个叫 JSESSIONID 的 Cookie。
有“信物” (老访客)：如果找到了 JSESSIONID，服务器就用它去自己的 Session 池里查找对应的 HttpSession 对象，并返回。
没有“信物” (新访客)：如果没找到 JSESSIONID（比如用户第一次登录），服务器会：
- ① 创建一个新的 HttpSession 对象 (在服务器内存里)。
- ② 生成一个唯一的、随机的 JSESSIONID 字符串。
- ③ 在准备发回给客户端的响应头里，自动加上 Set-Cookie: JSESSIONID=...。
- ④ 将新创建的 Session 对象返回。

结论：你只要调用了 request.getSession()，服务器就会确保客户端最终会收到一个 JSESSIONID Cookie。 客户端（浏览器/小程序）收到后会自动保存，并在后续所有请求中自动携带它。

这就是为什么你的应用不知不觉中就变成了“有状态”的。

⚠️ 混合模式会引发什么行为和问题？

这种设计会导致你的系统同时拥有两套“身份记忆”，一套在客户端（JWT），一套在服务端（Session），从而引发一系列问题。

1. 逻辑混乱与“双重标准”

行为: 一个请求到来时，它可能只带了 JWT，也可能只带了 JSESSIONID Cookie，或者两者都带了。你的系统需要如何判断优先级？
问题:
- 后续代码如何获取用户？ 业务层的 Controller 应该从哪里获取当前用户 ID？是从 request.getAttribute()（由无状态拦截器注入），还是从 httpSession.getAttribute()？这会导致开发规范不统一，代码可读性下降。
- 登出逻辑复杂化: 用户点击“退出登录”时，你不仅要让前端删除 JWT，还必须想办法让服务器端的 Session 失效。如果只清除了前端 Token，用户依然可以通过旧的 Cookie 访问系统！

2. 丧失“无状态”的核心优势——可扩展性

行为: 每次合法的 JWT 请求都会在服务器上创建一个 Session 对象。
问题:
- 服务器内存压力: 你又回到了有状态架构的老路，每个在线用户都会在服务器上占用一份内存。
- 分布式部署噩梦: 如果你将应用部署到多台服务器上进行负载均衡，Session 共享的问题就又回来了。用户在服务器 A 登录创建了 Session，下一个请求被转发到服务器 B，服务器 B 上没有这个 Session，用户就会被判断为未登录（除非你引入 Redis 等外部存储来共享 Session）。这使得 JWT 带来的最大优势——轻松横向扩展——荡然无存。

3. 潜在的安全风险

行为: JWT 和 Session 的生命周期是独立的。
问题:
- 生命周期不一致: 假设你的 JWT 有效期是 1 小时，而 Session 的默认有效期是 30 分钟不活动。一个用户用一个快要过期的 JWT 访问了系统，验证通过后，服务器会刷新这个用户的 Session 的活跃时间。这意味着，即使用户的 JWT 在下一分钟就过期了，他依然可以在接下来的 30 分钟内，仅凭浏览器 Cookie 就能继续访问系统。这破坏了 JWT 精确的生命周期控制。
- CSRF 攻击风险: 纯粹的 JWT 方案（Token 存储在 localStorage 并通过 Authorization 头发送）天然地可以防御 CSRF (Cross-Site Request Forgery, 跨站请求伪造) 攻击。但一旦你引入了基于 Cookie 的 Session，你就必须重新考虑并部署传统的 CSRF 防御措施（如 CSRF Token）。