JSON WEB TOKEN（JWT）的分析

JSON WEB TOKEN（JWT）的分析

一般情况下，客户的会话数据会存在文件中，或者引入redis来存储，实现session的管理，但是这样操作会存在一些问题，使用文件来存储的时候，在多台机器上，比较难实现共享，使用redis来存储的时候，则需要引入多一个集群，这样会增加管理的工作量，也不方便。有一个直观的办法，就是将session数据，存储在客户端中，使用签名校验数据是否有篡改，客户请求的时候，把session数据带上，获取里面的数据，通过校验，然后进行身份认证。

数据存储在客户端中，会存在一些挑战：

• 数据安全问题
• 数据量不能太大
• 续签的问题
• 注销的问题

为了实现客户端存储会话数据的解决方案，制定了JSON Web Token的协议，详细的协议可以在:RFC7529查看。下面我们看看jwt协议是怎样解决上面的挑战的。

JWT的结构：

JWT加密后，使用的格式，分为三部分，header，payload和signature，使用.号连接起来：

Header.Payload.Signature

JWT的header：

JWT的header，定义了存储的算法和协议名称：

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

JWT的Payload：

下面这些负载字段，是JWT协议提供选用，一般情况下，payload的数据是不加密存储在客户端中的，所以要注意不要存储敏感信息：

iss (issuer)：签发人
exp (expiration time)：过期时间
sub (subject)：主题
aud (audience)：受众
nbf (Not Before)：生效时间
iat (Issued At)：签发时间
jti (JWT ID)：编号

payload除了这些字段，还可以扩展一些数据，更加符合我们的需求：

{
    "iss": "foo",
    "extend_data": "hell"
}

JWT的Signature

服务端，有一个秘钥，通过秘钥对header和payload进行签名，使用header中指定的签名算法类型，一般有HMAC，RSA和ECDSA，下面是签名的格式：

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

JWT的通讯方式

JWT一般会将token数据存储在http请求的header中，通过Bearer来分隔：

headers: {
    'Authorization': 'Bearer ' + token
}

定义好数据结构和通讯方式，下面看看如何处理一些问题：

续签问题

每一个token产生，都应该限制好过期时间，确保只能在一段时间内有效，保证安全。当达到过期时间时，需要对token进行续签，可以定时想服务器提交请求，重新获取token来实现。

注销问题

当客户登录的时候，需要注销登录会话，由于token是没有状态的，只能在客户端把token删除，伪造一个注销的状态，真正的注销只能等待token过期。

也可以有种办法，就是把token的信息记录在redis中，当客户退出时，讲redis中的token删除，而一般请求时，会通过redis对数据进行校验，这样可以实现真的注销效果，但要引入多一个组件，把token变为有状态，如果用这种办法，也就不符合token存储在客户端的模式了

总结

如果能够支持，会话用的数据量较小，对注销可以等待超时的长效的场景，使用jwt作为会话数据存储是会比较方便的。而对于会话数据量大的场景，还是使用一般的方式比较好点。

参考资料

RFC7529