黑马程序员技术交流社区

标题: 【上海校区】JWT与Session的比较 [打印本页]

作者: biu波儿了罢    时间: 2019-9-21 10:17
标题: 【上海校区】JWT与Session的比较
本帖最后由 biu波儿了罢 于 2019-9-21 10:19 编辑

JWT与Session的比较
如今,越来越多的项目开始采用JWT作为认证授权机制,那么它和之前的Session究竟有什么区别呢?今天就让我们来了解一下。
JWT是什么

定义
    JSON Web Token(JWT)是一个开放标准(RFC 7519),它定义了一种紧凑和自包含的方式,用于在各方之间作为JSON对象安全地传输信息。作为标准,它没有提供技术实现,但是大部分的语言平台都有按照它规定的内容提供了自己的技术实现,所以实际在用的时候,只要根据自己当前项目的技术平台,到官网上选用合适的实现库即可。

特点
     使用JWT来传输数据,实际上传输的是一个字符串,这个字符串就是所谓的json web token字符串。所以广义上,JWT是一个标准的名称;狭义上,JWT指的就是用来传递的那个token字符串。这个串有两个特点:


结构

     它由三部分组成:header(头部)、payload(载荷)、signature(签名),以.进行分割。(这个字符串本来是只有一行的,此处分成3行,只是为了区分其结构)



Session的区别
      为什么我们要把JWTSession做对比呢?因为我们主要在每一次请求的认证时会用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本身就没有太多含义,只需修改服务端中存储的数据即可。

适用场景
JWTJWT的最佳用途是一次性授权Token,这种场景下的Token的特性如下:
真实场景的例子——文件托管服务,由两部分组成:
如何把JWT用在这个场景中呢?
[Java] 纯文本查看 复制代码
{
    "file": "/books/我这一辈子.pdf",
    "exp": 1500719759621
}


SessionSession比较适用于Web应用的会话管理,其特点一般是:

总结
     我们使用JWT,并不是说看到它新就用,而应该考虑其适用场景,如果需要进行管理,可以考虑使用Session,毕竟其方案更加成熟。





文章摘自:https://juejin.im/post/5d80546f6fb9a06b1a56be25










欢迎光临 黑马程序员技术交流社区 (http://bbs.itheima.com/) 黑马程序员IT技术论坛 X3.2