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