导读

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

Session和Token的对比

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

可是呢，如果你读过我之前写的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 timeCalendar calendar = Calendar.getInstance();calendar.add(Calendar.SECOND, 90);// create jwtHashMap<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?!~就是我们自己规定的随机盐，也就是根据这个片段对我们发送的数据进行加密。因为这个片段基本上只有开发着自己知道，所以安全性还是可以保证的。但是，安全性可不仅限于用户自己使用。

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

是不是有点能理解了呢？