JWT简介：从Session到Token的转变

Bertha 。 2022-12-23 03:20 236阅读 0赞

### 从Session过渡到Token ###

*  导读
 *  \`Session\`和\`Token\`的对比
 *  \`Token\`的结构
 *   *  头部
     *  负载
     *  签名
 *  一个小例子
 *  随机盐

# 导读 #

**`JWT`，全称`Json Web Token`。我们平常所说的`token`实际上就是说`JWT`技术中的`T`。**

# `Session`和`Token`的对比 #

如果你对`jsp`和`Servlet`非常熟悉，你应该对`Session`非常熟悉。每当用户登录的时候都会使用`Cookie`和`Session`联动起来，服务端使用`session.setAttribute()`方法完整地保存用户的信息，并使用`session.getAttribute()`方法完整地获取用户的信息。听起来非常方便？

可是呢，如果你读过我之前写的[`Session`工作原理][Session]，你会发现：`Session`对于服务器的压力还是相当大的。如果项目突然迎来了海量数据和大量并发，服务器宕机的概率大大增加，对于已经落地的项目甚至会产生不可逆转的错误。

于是，用户在线时就每时每刻维护一个`Session`的方法逐渐被摒弃；进而选择了用户每次请求的时候发送用户信息，顺便检查权限。一举两得，岂不美哉？`JWT`就应运而生了。在分布式场景中，仅在请求时服务器产生少许压力的`token`也就比始终给服务器施加压力并无法释放的`Session`更为实用。

# `Token`的结构 #

`Token`本质上是一串字符串，其中包含三个部分，三个部分分别是**头部**、**负载**和**签名**，每个部分由英文句号`.`来分开。

为什么这么做？因为这个字符串可以直接作为用户的标识，一旦被其他人截获，便能够直接作为请求使用。所以，我们往往会将这三个部分使用`Base64`算法进行编码，请求发送到服务器之后再将信息使用`Base64`算法进行解码。

## 头部 ##

**头部**主要是包含两段信息：**数据类型**和**签名算法**。

**数据类型**一般是选择`JWT`作为数据类型，不同于一般的`Json`又不同于普通的字符串；

**签名算法**一般是选择`HS256`，这也是官方推荐的算法。

## 负载 ##

第二个部分则是**负载**，也作**有效负载**。其中包含了一些有必要的数据声明。比如，我们可以将用户`id`和用户权限码等等非常重要的信息。

但是呢，如果你发送的信息真的被截获了，还是会被很简单的解码获得了信息，所以只能在这部分只能尽可能不要放一些敏感信息，否则会被盗号。

同样的，这部分也会使用`Base64`算法编码。

## 签名 ##

**签名**就像是交付的时候有个安全员通过唯一指定的识别器来确认操作的用户确实是你，而不是其他的什么人。

所以签名这部分就是头部和负载的结合，再使用一个**随机盐**再次编码。每当用户发送请求的时候，服务器都会首先使用第一部分和第二部分使用**只有服务器知道**的随机盐加密，再和第三部分比对。加密后的信息和第三部分是相同的，那么就是正确的，本次识别器确认了用户信息，否则就是非法登录。

这个算法从逻辑上能够在一定程度上保证请求信息不会被其他用户非法使用。但是呢，这个算法还是不能够保证别有用心的人修改你的个人隐私。这就很无奈了。

# 一个小例子 #

这个小例子虽然用到了`SpringBoot`，但是只使用了框架内的测试功能，单纯地使用命令行输出所有的结果。

由于我们并没有用到`SpringBoot`自带的测试类，所以就只是单纯地在`{项目根目录}/src/main/test/{自定义包名}`下新建`JWTTest.java`，并直接使用`JWT`工具类：

@Test
    public void testJWT() { 
      // set expire time
      Calendar calendar = Calendar.getInstance();
      calendar.add(Calendar.SECOND, 90);
      // create jwt
      HashMap<String, Object> headers = new HashMap<>();
      headers.put("type", "JSON");
      String token = JWT.create()
                        .withHeader(headers)
                        .withClaim("user", "sakebow")
                        .withClaim("id", "20202104126")
                        .withExpiresAt(calendar.getTime())
                        .sign(Algorithm.HMAC256("~@#sakebow?!~"));
      System.out.println(token);
    }

这段代码运行之后就会生成一长串代码：

`eyJ0eXAiOiJKV1QiLCJ0eXBlIjoiSlNPTiIsImFsZyI6IkhTMjU2In0.eyJpZCI6IjIwMjAyMTA0MTI2IiwiZXhwIjoxNjAwNjAwNjM1LCJ1c2VyIjoic2FrZWJvdyJ9.xigradwatkwZYO1QZJ98_sa6qH9L-_8uYyi5_HUSRjE`

看起来毫无章法？不过没有关系，我们还能解码。

@Test
    public void testDecodeJWT() { 
      String token =  "eyJ0eXAiOiJKV1QiLCJ0eXBlIjoiSlNPTiIsImFsZyI6IkhTMjU2In0.eyJpZCI6IjIwMjAyMTA0MTI2IiwiZXhwIjoxNjAwNjAwNjM1LCJ1c2VyIjoic2FrZWJvdyJ9.xigradwatkwZYO1QZJ98_sa6qH9L-_8uYyi5_HUSRjE";
      JWTVerifier jwtVerifier = JWT
              .require(Algorithm.HMAC256("~@#sakebow?!~"))
              .build();
      DecodedJWT decodedJWT = jwtVerifier.verify(token);
      System.out.println(decodedJWT.getHeader() + ", " + decodedJWT.getPayload());
    }

`JWTVerifier`除了解码以外，还会核对前面两个部分合在一起加密是否与最后一段相等。同时，`JWT`还会经常变化，这也正为`JWT`提供了一定的安全性。

# 随机盐 #

不知道你们注意到没有，在`JWT`加密中有一段代码：

sign(Algorithm.HMAC256("~@#sakebow?!~"));

实际上这个`~@#sakebow?!~`就是我们自己规定的**随机盐**，也就是根据这个片段对我们发送的数据进行加密。因为这个片段基本上只有开发着自己知道，所以安全性还是可以保证的。但是，安全性可不仅限于用户自己使用。

如果说其他别有用心的用户拿到了这个数据，伪造了其他人的信息，发送了非法请求，到了服务器结果就会被当成已经授权的人，然后回应请求。这将会让整个程序会变得非常危险。所以，这段随机盐**决不可以保存在客户端**。

是不是有点能理解了呢？

[Session]: https://blog.csdn.net/ordinary_brony/article/details/109909083