摘要：Cookie、Session和JWT都不是什么新的技术了，最近用到了就比较和总结下。

我们知道http协议是无状态的，用户登录后如何验证和保存用户状态呢？下面来介绍

1. 使用Cookie和Session验证登录状态

        session是保存在服务端的一种数据结构，用来跟踪用户状态，使得在跨页面的时候依然可以可以识别用户信息；cookie保存在客户端一小段数据，用于识别用户跟踪用户的会话信息、存储用户偏好设置、实现购物车功能等，服务器可以在 HTTP 响应头中设置一个或多个 Cookie，并发送给用户的浏览器，浏览器接收到 Cookie 后会将其存储在本地，以便在之后的请求中将这些信息发送回服务器。

        通常会使用基于cookie和session的验证流程，大致步骤如下：

• 用户登录：用户输入用户名和密码进行登录，通过http请求发送给服务端；
• 创建session：服务器验证用户身份，如果验证通过，则创建一个唯一的会话标识符（Session ID），并在服务器端保存用户的会话状态信息；
• 响应set-cookie: 服务器将生成的 Session ID 返回给客户端（响应headers的set-cookie中），客户端将 Session ID 存储在 Cookie 中；
• 再次发送请求：客户端会在后续请求中携带cookie（cookie通常包括名称、值、域、路径、过期时间、安全标志等）；
• 验证：服务端接收到请求时，会读取 Session ID，并根据该 ID 在服务器端查找对应的会话状态信息，以确定用户的身份和权限，最终返回特定数据。

2. session的安全性与缺点

2.1 session的安全性

        由于Session涉及到用户登录网站并与网站进行交互的整个过程，其安全性是网站安全防护中的一个重要方面。如果Session被劫持，可能会导致用户账户被恶意登录、网站被篡改，甚至登录网站后台，获取管理员权限。

        虽然session通常设置HttpOnly禁止前端读取，只能浏览器读取（HTTPS设置Secure）。但是还需要从多方面才采取措施提高安全：

• 确保生成Session ID 具有足够的随机性，避免预测性和重复性。Session ID在不同的版本和软件中不同，通常的session ID生成规则： 随机数加时间加上JVM的ID值；

按照规则生成的session ID：
JSESSIONID=E0B8F15BF5ADF35ACFD741BC85CDF5CB; Path=/; HttpOnly;

• 在传输 Session ID 时采用 HTTPS 协议，确保数据在传输过程中进行加密，防止被中间人攻击截取。
• 用户登录后重新生成 Session ID，避免使用登录之前的 Session ID，或使用用框架或库提供的防范措施，如Spring Security中的SessionManagementFilter。
• Session注销机制，设置合理的 Session 过期时间，在一定时间内用户无操作自动失效。
• 避免在 Session 中存储敏感信息对于需要在 Session 中存储的信息，进行加密处理或者对数据进行适当的脱敏处理。
• 记录 Session 操作日志，监控 Session 活动，及时发现异常活动，如异地登录等，便于追踪和排查问题。

2.2 session的缺点

        服务器端资源消耗：每个用户会话都需要在服务器端维护相应的状态信息，这可能会消耗大量的内存和服务器资源，尤其是在高并发场景下。

        扩展性差：尤其对于服务器集群，或者是跨域的服务导向架构，要求 session 数据共享，如何解决每台服务器都可以读取Session。此时的解决方案可以是Session数据持久化，写入数据库（如Redis）或者别的持久层，所有服务都想持久层请求Session数据。但是这样做的工作量巨大，且依然存在持久层挂了的风险。另一种方案就是使用JWT，将相关数据存储在客户端，下接将详细介绍JWT方案。

3. JWT 介绍

3.1 JWT的原理

        JSON Web Tokens（缩写 JWT）是目前最流行的跨域认证解决方案[1]，解决了Session验证资源消耗和扩展性差的缺点。其官网是：

JSON Web Tokens - jwt.ioJSON Web Token (JWT) is a compact URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is digitally signed using JSON Web Signature (JWS).https://jwt.io/

        首先，JWT的组成包括三个部分 ： Header.Payload.Singnature

        Header部分：主要包括alg属性和typ属性。alg表示签名算法(algorithm)，默认是HMAC SHA256(写成HS56)；typ表示令牌(token)类型(type)，JWT令牌统一写为JWT。

        通过base64url的转码，生成JWT中的显示内容（可使用一下链接验真Base64URL Code:https://thrysoee.dk/base64url/ ），此处为：eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

{
  "alg": "HS256",
  "typ": "JWT"
}

        Payload部分：消息体用于存放业务数据，是一个JSON对象。注意，JWT 默认是不加密的，任何人都可以读到，所以不要把秘密信息放在这个部分。

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

        Signature 部分：对前两部分的签名，验证消息的完整性和真实性，防止数据篡改。签名的计算要使用 Header 中指定的算法和秘钥，确保只有持有秘钥的一方才能生成有效的签名。通过secret进行算法的签名，这样任何对于内容的篡改都会被识别出来

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload), 
  your-256-bit-secret
) secret base64 encoded

3.2 JWT和 Session的比较

        先看下JWT的流程，于cookie和session类似，主要区别在于session验证是将相关信息存储在服务器这一端，而JWT没有将任何信息存储在服务器。

        上面我们已经介绍session具有简单、方便的优点，也具有扩展性差、需要存储数据的缺点。对于JWT来说的优缺点：

优点： 减少存储开销、可扩展性强、同时用于认证和交换信息、防止被伪造和篡改

缺点：默认不加密，不适合保存敏感信息、无法临时废止、登出需要额外处理、有效期不易评估、网络开销相对高（Token比较长）

4. 实操用户验证从session升级为JWT

        下面将介绍将Session登录验证升级为JWT，通过将JWT的Token返回给用户，并在登录时使用headers 带上Token验证：

        首先，pom.xml先引入依赖java-jwt

<!-- pom.xml中引入生成JWT的依赖 -->
<dependency>
  <groupId>com.auth0</groupId>
  <artifactId>java-jwt</artifactId>
  <version>3.14.0</version>
</dependency>

        然后，使用 Java-JWT 库来生成 JWT Token ，具体过程如下：

1. 创建加密算法对象 Algorithm： Algorithm algorithm = Algorithm.HMAC256(Constant.JWT_KEY); 使用 HMAC256 加密算法，并传入预设的密钥 Constant.JWT_KEY 来创建一个加密算法对象。 algorithm。 HMAC256 是一种基于哈希函数的消息认证码算法，用于对数据进行完整性验证和身份认证。

2. 生成 JWT Token： String token = JWT.create()...sign(algorithm); 调用 JWT.create() 方法创建一个 JWT Token 构建器对象，该对象用于设置 JWT 的各种声明和信息。 使用 withClaim(key, value) 方法为 Token 添加声明（Claim），其中： Constant.USER_NAME：将用户的用户名作为声明的键，对应 user.getUsername() 方法返回的值； Constant.USER_ID：将用户的 ID 作为声明的键，对应 user.getId() 方法返回的值； Constant.USER_ROLE：将用户的角色作为声明的键，对应 user.getRole() 方法返回的值； withExpiresAt(date)：设置 Token 的过期时间，即 Token 在指定的时间点之后将会失效。 sign(algorithm)：使用之前创建的加密算法对象 algorithm 对 Token 进行签名，确保 Token 的完整性和安全性。

3. 生成 Token 字符串：

   最终将生成的 JWT Token 转换为字符串形式，并赋值给变量 token。具体代码如下

@GetMapping("/loginWithJwt") // 定义URL
@ResponseBody  //Spring会自动将Controller方法的返回值转换为适当的响应格式（如JSON、XML等），并将其作为HTTP响应的实体内容返回。
public ApiRestResponse loginWithJwt(@RequestParam String userName, @RequestParam String password) throws ImoocMallException {
    // userName和password不能为空校验
    if(StringUtils.isEmpty(userName)){
        return ApiRestResponse.error(ImoocMallExceptionEnum.NEED_USER_NAME);
    }
    if(StringUtils.isEmpty(password)){
        return ApiRestResponse.error(ImoocMallExceptionEnum.NEED_PASSWORD);
    }
    // 密码长度不能小于8位
    if(password.length()<8){
        return ApiRestResponse.error(ImoocMallExceptionEnum.PASSWORD_TOO_SHORT);
    }
    User user = userService.login(userName,password);
    user.setPassword(null);  // 保存用户信息时，不保存密码；避免password被直接返回，导致不安全
    // 生成JWT
    Algorithm algorithm = Algorithm.HMAC256(Constant.JWT_KEY);  // JWT_KEY用于对JWT加解密
    String token = JWT.create()
            .withClaim(Constant.USER_NAME, user.getUsername())
            .withClaim(Constant.USER_ID, user.getId())
            .withClaim(Constant.USER_ROLE, user.getRole())
            // 过期时间
            .withExpiresAt(new Date(System.currentTimeMillis() + Constant.EXPIRE_TIME))
            .sign(algorithm);
    return ApiRestResponse.success(token);
}

        使用Postman验证接口生成的JWT，如图

        将上述上述JWT值放入官网，验证JWT中解析的内容和接口请求携带的内容是否一致。

        完成JWT的生成，登录后如何校验？此时需要在升级过滤器Filter中的校验逻辑。

        首先，通过强制类型转换获取 HttpServletRequest 对象，并从请求头中获取 JWT Token，即 token 变量。

        然后，处理请求执行校验逻辑。若请求方法是 OPTIONS，则直接放行，不做任何处理。

        若请求方法非 OPTIONS，判断 token 是否为空：

        token为空即用户未登录，则提示客户端需要提供 JWT Token，并结束请求。

        token不为空，则进行JWT Token验证。使用 HMAC256 算法和预先定义的常量 JWT_KEY 初始化算法，然后通过 JWTVerifier 对象进行验证，通过则返回一个DecodedJWT对象 jwt，其包含了解码后的JWT Token信息。再解析其中的用户信息，并将用户信息存储到 currentUser 对象中，并通过 userThreadLocal 存储到当前线程的 ThreadLocal 中。若 token 过期或解码失败，则抛出相应的异常。

        最后，对于通过身份验证的请求，继续执行原有的业务逻辑，调用 filterChain.doFilter 方法传递给下一个过滤器或目标 Servlet 处理。

        具体代码实现如下：

public static ThreadLocal<User> userThreadLocal = new ThreadLocal();
public User currentUser = new User();

@Override
public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
    HttpServletRequest request = (HttpServletRequest) servletRequest;
    String token = request.getHeader(Constant.JWT_TOKEN); // 前后端约定好key,此处为jwt_token
    if ("OPTIONS".equals(request.getMethod())) {
        filterChain.doFilter(servletRequest, servletResponse);
    } else {
        if (token == null){  // 检验是否登录,未登录则
            PrintWriter out = new HttpServletResponseWrapper((HttpServletResponse) servletResponse).getWriter();
            out.write("{\n"
                    + "    \"status\": 10007,\n"
                    + "    \"msg\": \"NEED_JWT_TOKEN\",\n"
                    + "    \"data\": null\n"
                    + "}");
            out.flush();
            out.close();
            return;
        }
        // 验证JWT 是否有效
        Algorithm algorithm = Algorithm.HMAC256(Constant.JWT_KEY);
        JWTVerifier verifier = JWT.require(algorithm).build();
        try {
            DecodedJWT jwt = verifier.verify(token);
            currentUser = new User();
            currentUser.setId(jwt.getClaim(Constant.USER_ID).asInt());
            currentUser.setRole(jwt.getClaim(Constant.USER_ROLE).asInt());
            currentUser.setUsername(jwt.getClaim(Constant.USER_NAME).asString());
            userThreadLocal.set(currentUser);
        } catch (TokenExpiredException e) {
            // token过期，抛出异常
            throw new ImoocMallException(ImoocMallExceptionEnum.TOKEN_EXPIRED);
        } catch (JWTDecodeException e) {
            // 解码失败，抛出异常
            throw new ImoocMallException(ImoocMallExceptionEnum.TOKEN_WRONG);
        }
    }

    // 通过校验，则原有逻辑继续执行
    filterChain.doFilter(servletRequest, servletResponse);
}

[1] JSON Web Token 入门教程 https://www.ruanyifeng.com/blog/2018/07/json_web_token-tutorial.html