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

内容来源于网络如有侵权请私信删除
你还没有登录,请先登录注册
  • 还没有人评论,欢迎说说您的想法!