如今,越来越多的项目开始采用JWT作为认证授权机制,那么它和之前的Session究竟有什么区别呢?今天就让我们来了解一下。 JWT是什么 定义
特点 使用JWT来传输数据,实际上传输的是一个字符串,这个字符串就是所谓的json web token字符串。所以广义上,JWT是一个标准的名称;狭义上,JWT指的就是用来传递的那个token字符串。这个串有两个特点:
结构 它由三部分组成:header(头部)、payload(载荷)、signature(签名),以.进行分割。(这个字符串本来是只有一行的,此处分成3行,只是为了区分其结构)
和Session的区别 为什么我们要把JWT和Session做对比呢?因为我们主要在每一次请求的认证时会用JWT,在此之前我们都是用Session的。那这两者的区别在哪儿呢? 本身的含义 看了前面的介绍,我们发现JWT这个字符串其实本身就包含了关于用户的信息,比如用户名、权限、角色等。 Session传递的sessionId虽然是一个更简单的字符串,但它本身并没有任何含义。 所以一般说来JWT的字符串要比sessionId长,如果你在JWT中存储的信息越长,那么JWT本身也会越长。 而Cookie的存储容量是有限制的(通常为4KB),所以大家在使用的时候需要注意。 解析方法 JWT的header和payload其实是有json转变过来的,而signature其实就是一个加密后的字符串,因此解析起来较为简单,不需要其他辅助的内容。 sessionId是服务器存储的用户对象的标识,理论上需要一个额外的map才能找出当前用户的信息。 管理方法 JWT理论上用于无状态的请求,因此其用户管理也只是依赖本身而已。我们一般是在它的payload中加入过期时间,在不增加额外管理的情况下,它只有自动过期的方式。 Session因为它本就是存储在服务器端的,因此管理方案就有很多,而且大多都很成熟。 跨平台 JWT本身就是基于json的,因此它是比较容易跨平台的,可以从官网下载不同平台的包,解析即可。 session的跨平台可能就不那么好做了,需要考虑的地方在于用户信息存储的格式,ProtoBuf、json、xml等,管理的话可能就需要专门的统一登录平台,这个就不展开了。 时效性 无状态JWT一旦被生成,就不会再和服务端有任何瓜葛。一旦服务端中的相关数据更新,无状态JWT中存储的数据由于得不到更新,就变成了过期的数据。 session就不一样了,sessionId本身就没有太多含义,只需修改服务端中存储的数据即可。 适用场景 JWT JWT的最佳用途是一次性授权Token,这种场景下的Token的特性如下:
真实场景的例子——文件托管服务,由两部分组成:
如何把JWT用在这个场景中呢?
{ 'file': '/books/我这一辈子.pdf', 'exp': 1500719759621}
Session Session比较适用于Web应用的会话管理,其特点一般是:
总结 我们使用JWT,并不是说看到它新就用,而应该考虑其适用场景,如果需要进行管理,可以考虑使用Session,毕竟其方案更加成熟。如果大家有什么新发现想和作者探讨的,欢迎在下方留言。 有兴趣的话可以关注我的公众号,说不定会有意外的惊喜。 |
|