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作为会话数据存储是会比较方便的。而对于会话数据量大的场景，还是使用一般的方式比较好点。