首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >不要把 JWT 用作 session

不要把 JWT 用作 session

作者头像
dys
发布2020-02-10 11:34:14
8250
发布2020-02-10 11:34:14
举报
文章被收录于专栏:性能与架构性能与架构

现在很多人使用 JWT 用作 session 管理,这是个糟糕的做法,下面阐述原因,有不同意见的同学欢迎讨论。

首先说明一下,JWT 有两种:

  • 无状态的 JWT,token 中包含 session 数据。
  • 有状态的 JWT,token 中仅有 session ID,session 数据还是存储在服务端。

本文讨论的是 “无状态的 JWT”,就是把用户的 session 数据放到 token 中。

JWT 不适合做为 session 机制,这么做是有危险的。

很多人喜欢比较 “cookies vs. JWT”,这种比较是无意义的,就像比较苹果和桔子,cookies 是一个存储机制,而 JWT 是加密签名的 token,他们不是对立的,可以一起使用,或者独立使用。

正确的比较是“sessions vs. JWT” 和 “cookies vs. Local Storage”。

JWT 宣称的优点

人们通常会说 JWT 有如下的好处:

  • 易于水平扩展
  • 简单易用
  • 加密,更安全
  • 内置过期功能
  • 可以防护 CSRF 攻击
  • 在用户阻止了cookies后还可以工作

对于这些所谓的好处我们会一一剖析。

(1)易于水平扩展

把 session 数据放入 JWT,服务端不需要保存 session 信息,那么服务端自然是无状态的,可以随意扩展。

看上去的确带来了扩展上的便利,但实际上没啥优势,服务器端保存 session 没有任何难度:

  • 多服务器场景:可以用专门的 redis 服务器保存 session。
  • 多集群场景:多集群间不需要共享 session,同一个用户始终分配到同一个集群即可。

这都是很成熟的解决方案,没有必要在客户端 token 中保存 session。

(2)简单易用

看似一个小小的 token 比较简单,实则不然,你需要自己去处理 session 的管理,怎么可能比开箱即用的 cookies 更简单。

(3)更安全

因为 JWT 是加密的,很多人认为其更加安全,cookies 没加密,不安全。

其实 cookies 只是存储机制,你完全可以使用加密签名的方式。

还有人认为 cookies 没加密会被拦截读取。

cookies 只是 HTTP 头信息,不负责安全,这个问题应该使用 TLS 来解决,否则,即使 JWT 也没法保证信息的安全。

(4)内置过期功能

这个功能更是没用,是否过期应该由服务端控制,不应交给客户端控制,否则,如果 token 被盗取,服务端将没有任何办法。

(5)可以防护 CSRF 攻击

简单说一下什么是 CSRF 攻击。

打个比方,你登录了网银,这时已经具备给其他账户转账的条件了,比如转账的接口地址是:

http://xbank.com/transfer?to=123&money=1000

在你没有退出网银之前,你访问了一个恶意网站,其中有一段代码:

<img src=http://xbank.com/transfer?to=456789&money=1000>

这样你就丢钱了。

这只是个朴实的例子,实际情况比这复杂得多,但归根结底,CSRF 攻击就是源于:隐式身份验证机制,就是 cookies 是自动发送给服务端的,无法保证该请求是用户批准的。

所以,很多人就认为使用 JWT 就没这个问题了,因为不用 cookies 了。

那么请问,你是把 JWT 保存在哪里的?有2个保存方式:

  • cookie:这样同样会面临 CSRF 攻击。
  • 其他地方,例如 Local Storage:这样的确避免了 CSRF,但暴露了更严重的安全问题,Local Storage 这类的本地存储是可以被 JS 直接读取的。

其实,防护 CSRF 攻击的正确方式只有:CSRF token。

(6)在用户阻止了cookies后还可以工作

不幸的是,在用户阻止了 cookies 的场景中,通常不仅仅是阻止 cookies,而是阻止所有的本地存储,包括 Local Storage。

这样的话,JWT 也同样无法工作。

JWT 的缺点

(1)体积大

如果把 session 信息编码后放入 token,那么其体积会很大,很有可能超出 cookie 的大小限制,那就只能把 JWT 保存在 Local Storage 了,也就产生了安全问题。

而且,体积大,网络压力就大了。

(2)不安全

这个问题上面分析过了,如果放在 cookie 里,那和传统的 session 方案就差不多了,如果放在别的地方,就有其他安全问题了。

(3)无法使某个 JWT 无效

不像 session,在服务端可以使其失效,而 JWT 直到其过期才能无效。

比如服务端检测到了一个安全威胁,也无法使相关的 JWT 失效。

也就是说,当你发现风险时,无法杀死某个 session,如果你想解决这个问题,就需要服务端可以对 session 进行管理,那么就变回有状态的模式了。

(4)session 数据旧了

session 数据是保存在 JWT 中的,其中会有用户的相关信息,例如角色。

在 JWT 过期之前,用户的角色发生了变化,那么这时 JWT 中的信息就是旧的了,因为无法更新。

小结

JWT 真的不适合当做 session 使用,JWT 更适合一次性的命令认证,设置一个很短的有效期。

本文的目的不是说 JWT 不好,而是想说把 JWT 用作 session 是用错了地方。

你是怎么使用 JWT 的?欢迎交流讨论。

翻译整理自:http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2020-01-02,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 JAVA高性能架构 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • JWT 宣称的优点
  • JWT 的缺点
  • 小结
相关产品与服务
多因子身份认证
多因子身份认证(Multi-factor Authentication Service,MFAS)的目的是建立一个多层次的防御体系,通过结合两种或三种认证因子(基于记忆的/基于持有物的/基于生物特征的认证因子)验证访问者的身份,使系统或资源更加安全。攻击者即使破解单一因子(如口令、人脸),应用的安全依然可以得到保障。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档