会话技术：Cookie、Session、JWT的优缺点分析与实践

会话技术

• 会话：用户打开浏览器，访问web服务器的资源，会话建立，直到有一方断开连接，会话结束。在一次会话中可以包含多次请求和响应。
• 会话跟踪：一种维护浏览器状态的方法，服务器需要识别多次请求是否来自同一浏览器，以便在同一次会话的多个请求间共享数据。
• 会话跟踪方案：
  • Cookie（客户端会话跟踪技术）
  • Session（服务端会话跟踪技术）
  • 令牌技术

为什么要共享数据呢？
由于 HTTP 是无状态协议，在后面请求中怎么拿到前一次请求生成的数据呢？此时就需要在一次会话的多次请求之间进行数据共享。

方案一：Cookie

cookie 是客户端会话跟踪技术，它是存储在客户端浏览器的。
比如第一次请求了登录接口，登录接口执行完成之后，我们就可以设置一个 cookie，在 cookie 当中存储用户的一些数据信息如用户名、id。
服务器端在给客户端响应数据的时候，会自动的将 cookie 响应给浏览器；浏览器接收到响应回来的 cookie 之后，会自动的将 cookie 的值存储在浏览器本地。接下来在后续的每一次请求中，都会自动的将浏览器本地所存储的 cookie 携带到服务端。
基于此，服务端可以判断获取的 cookie 的值是否存在，如果存在说明客户端之前已经登录完成了。这样我们就可以基于 cookie 在同一次会话的不同请求之间来共享数据。

为什么上面都是自动的进行的？
因为 cookie 是HTTP协议当中所支持的技术，而各大浏览器厂商都支持了这一标准。在 HTTP 协议官方给我们提供了一个响应头和请求头：

• 响应头 Set-Cookie ：设置Cookie数据的
• 请求头 Cookie：携带Cookie数据的

案例测试

@Slf4j
@RestController
public class SessionController {
    // 设置Cookie
    @GetMapping("/c1")
    public Result cookie1(HttpServletResponse response){
        response.addCookie(new Cookie("login_username", "admin"));  //设置cookie/响应cookie
        return Result.success();
    }

    // 获取cookie
    @GetMapping("/c2")
    public Result cookie2(HttpServletRequest request){
        Cookie[] cookies = request.getCookies();
        for (Cookie cookie : cookies) {
            if (cookie.getName().equals("login_username")){
                System.out.println("login_username" + cookie.getValue());  //输出获取的指定cookie
            }
        }
        return Result.success();
    }
}

Cookie的优缺点

• 优点：HTTP协议中支持的技术（像Set-Cookie 响应头的解析以及 Cookie 请求头数据的携带，都是浏览器自动进行的，是无需我们手动操作的）
• 缺点：
  • 移动端APP无法使用 Cookie
  • 不安全，用户可以自己禁用 Cookie
  • Cookie 不能跨域

跨域：
假如前端部署在服务器192.168.150.200，端口80上，后端部署在 192.168.150.100，端口8080上；那么我们打开浏览器访问前端工程url：http://192.168.150.200/login.html，假设服务端访问接口地址为：http://192.168.150.100:8080/login，此时就存在跨域操作了。
如果服务器设置了一个Cookie，这个Cookie是不能使用的，因为Cookie无法跨域。
区分跨域的三个维度：

协议 —— ip/域名 —— 端口

只要三个有一个维度不同，就是跨域操作。

方案二：Session

Session 是服务端会话跟踪技术，它是存储在服务器端的。Session 的底层其实就是基于Cookie来实现的。
如果浏览器是第一次请求服务器，这时服务器会自动创建一个会话对象 Session（每一个会话对象 Session 都有一个 ID）；服务器给浏览器响应数据时，会将 Session 的 ID 通过 Cookie 响应给浏览器，Cookie的名字是固定的 JESSIONID=ID；浏览器会自动识别这个响应头，然后将Cookie存储在浏览器本地。后续每次请求浏览器都会将 Cookie 携带到服务端。

案例测试

	// 往session中存储数据
    @GetMapping("/s1")
    public Result session1(HttpSession session){
        log.info("HttpSession-s1: {}", session.hashCode());
        session.setAttribute("loginUser", "tom");  //往session中存储数据
        return Result.success();
    }

	//从session中获取数据
	@GetMapping("/s2")
    public Result session2(HttpServletRequest request){
        HttpSession session = request.getSession();
        log.info("HttpSession-s2: {}", session.hashCode());

        Object loginUser = session.getAttribute("loginUser");  //从session中获取数据
        log.info("loginUser: {}", loginUser);
        return Result.success(loginUser);
    }

Session 的优缺点

• 优点：Session是存储在服务端的，安全
• 缺点：
  • 服务器集群环境下无法直接使用Session
  • Cookie 的缺点

服务器集群环境为何无法使用Session？
集群下同一个项目会部署多份。用户会访问一台前置的服务器，叫负载均衡服务器，再将请求均匀的分发给后面的多台服务器。因此多个请求可能分发给了不同服务器，其他服务器当中就没有这个ID的会话对象Session了。

为了解决上面这些问题，现在企业开发中基本都会采样第三种方案，通过令牌技术来进行会话跟踪。

方案三：令牌技术

令牌就是一个用户身份的标识，本质是一个字符串。

如果通过令牌技术来跟踪会话，在第一次请求（如登录）成功的时候，我们就可以生成一个令牌，，令牌就是用户的合法身份凭证；接下来在响应数据时，直接将令牌响应给前端；前端接收到令牌后，需要将这个令牌存储起来，可以存储在 cookie 中，也可存储在其他的存储空间（如 localStorage）当中。后续每次请求都需要将令牌携带到服务端，服务端检验令牌有效性。
令牌 的优缺点

• 优点：
  • 支持 PC端、移动端
  • 解决集群环境下的认证问题
  • 减轻服务器的存储压力（无需在服务器端存储）
• 缺点：
  • 需要自己实现（包括令牌的生成、令牌的传递、令牌的校验）

JWT令牌

介绍

JWT 全称：JSON Web Token（官网：https://jwt.io/）

• 定义了一种简洁的、自包含的格式，用于在通信双方以 json 数据格式安全的传输信息。由于数字签名的存在，这种信息是可靠的。

  简洁：是指 jwt 就是一个简单的字符串。
  自包含：指 jwt 令牌看似是一个随机的字符串，但是我们可以根据自身的需求在 jwt 令牌中存储自定义的数据内容（如用户的相关信息）。
  简单来讲，jwt就是将原始的json数据格式进行了安全的封装，这样就可以直接基于jwt在通信双方安全的进行信息传输了。

JWT的组成：

• Header(头）：记录令牌类型、签名算法等。 例如：{“alg”:“HS256”,“type”:“JWT”}
• Payload(有效载荷）：携带一些自定义信息、默认信息等。 例如：{“id”:“1”,“username”:“Tom”}
• Signature(签名）：防止Token被篡改、确保安全性。结合header、payload，并加入指定秘钥，通过指定签名算法计算而来。
  正是因为签名的存在，所以整个 jwt 令牌是非常安全可靠的。
  

JWT 如何将原始的 json 格式数据转为字符串的呢？
进行 Base64编码：一种基于64个可打印的字符（A-Z a-z 0-9 + /）来表示二进制数据的编码方式。此外还有等号用于补位。
签名部分是通过指定的签名算法计算出来的。

---

JWT令牌最典型的应用场景就是登录认证：

1. 在浏览器发起请求来访问登录的接口，如果登录成功之后，我们需要生成一个jwt令牌，将生成的 jwt令牌返回给前端。
2. 前端拿到jwt令牌之后，会将jwt令牌存储起来。在后续的每一次请求中都会将jwt令牌携带到服务端。
3. 服务端统一拦截请求之后，先来判断一下这次请求有没有把令牌带过来，如果没有带过来，直接拒绝访问，如果带过来了，还要校验一下令牌是否是有效。如果有效，就直接放行进行请求的处理。

生成和校验

需要先引入 JWT 的依赖：

<!-- JWT依赖-->
<dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt</artifactId>
    <version>0.9.1</version>
</dependency>

生成JWT令牌的代码实现：

@Test
public void testGenerateJwt(){
	HashMap<String, Object> claims = new HashMap<>();
	claims.put("id", 1);
	claims.put("name", "tom");
	// 构建 JWT 令牌
	String jwt = Jwts.builder()
			.signWith(SignatureAlgorithm.HS256, "itcitel")  //签名算法, 密钥
			.setClaims(claims)  //自定义内容（载荷）
			.setExpiration(new Date(System.currentTimeMillis() + 3600 * 1000))  //设置有效期为1h
			.compact();//将JWT转换为紧凑的字符串表示：以Base64编码压缩头部和载荷，并在之后添加签名
	System.out.println(jwt);
}

下面校验生成的JWT令牌（解析）：

@Test
public void testParseJwt(){
	Claims claims = Jwts.parser()
			.setSigningKey("itcitel")  //签名密钥(必须和生成令牌时使用的相同)
			.parseClaimsJws("eyJhbGciOiJIUzI1NiJ9.eyJuYW1lIjoidG9tIiwiaWQiOjEsImV4cCI6MTcwNjUwMDQ5NH0.Bs_W_knSJ9hCFL-lwEB_kXlYr3rewgskF62AMJAA37k")
			.getBody();
	System.out.println(claims);
}

令牌解析后，可以看到id和过期时间，如果在解析的过程当中没有报错，就说明解析成功了。

登录下发令牌案例

@Slf4j
@RestController
@CrossOrigin
public class LoginController {
    @Autowired
    private UserService userService;

    @PostMapping("/login")
    public Result login(@RequestBody User user){
        log.info("用户登录：{}", user);
        User u = userService.login(user);
        // 如果登录成功，生成令牌，下发令牌
        if (u != null){
            Map<String, Object> claims = new HashMap<>();
            claims.put("id", u.getId());
            claims.put("name", u.getUsername());

            String jwt = JwtUtils.generateJwt(claims);
            return Result.success(jwt);
        }
        return Result.error("用户名或密码错误");
    }
}