近期使用token的机制来实现用户鉴权是越来越流行了,最近公司这类的项目也是超多。因此就把以前学过的JWT捡起来,特此贴出博客分享我的总结,也是为了方便温习。
我的实践
在项目中使用JWT的话,通常我会引用auth0,基于auth0编写一个工具类;工具类普遍编写两个方法,那就是创建JWT token和解码(认证)JWT token。auth0用来生成和校验token,底层一定有很多算法和转码的功能,有兴趣可以阅读源码。
对JWT还不了解的小伙伴可以看看阮哥的文章 > http://www.ruanyifeng.com/blog/2018/07/json_web_token-tutorial.html
下面看看我对JWT的总结吧~
JWT总结
JWT的特点
- JWT 默认是不加密,但也是可以加密的。生成原始 Token 以后,可以用密钥再加密一次。
- JWT 不加密的情况下,不能将秘密数据写入 JWT。
- JWT 不仅可以用于认证,也可以用于交换信息。有效使用 JWT,可以降低服务器查询数据库的次数。
- JWT 的最大缺点是,由于服务器不保存 session 状态,因此无法在使用过程中废止某个 token,或者更改 token 的权限。也就是说,一旦 JWT 签发了,在到期之前就会始终有效,除非服务器部署额外的逻辑。
- JWT 本身包含了认证信息,一旦泄露,任何人都可以获得该令牌的所有权限。为了减少盗用,JWT 的有效期应该设置得比较短。对于一些比较重要的权限,使用时应该再次对用户进行认证。
- 为了减少盗用,JWT 不应该使用 HTTP 协议明码传输,要使用 HTTPS 协议传输。
从特点中看优点
- JSON的通用性,决定了JWT是个跨语言的技术
- JWT token对于sessionid的方案来说,JWT可以携带任何我们想要用到的信息;因为在JWT token的负载当中我们可以放入认证信息或者权限相关的信息。因此高效利用JWT,能够大大提升我们的系统性能,减少与数据库的交互。
- 安全性高,防止token伪造和篡改;并不是说我们放在token中的数据安全性高,因为JWT默认不加密而仅仅是将JSON数据转码了。JWT token几乎不可能伪造、篡改,因为token是否正确的唯一校验者是我们后台的秘钥。
- JWT token是自校验的形式,不需要任何其他请求和数据库操作,使我们系统管理会话更高效;刚刚接触JWT有可能会疑惑:为啥服务器不存储token,就可以校验是否可用。因为JWT验证是基于密码学的签名算法的,JWT签名就是使用header指定的算法把header和Payload进行了转码后的字符串,所以说硬编码的形式就可以比较签名是否正确。这里有必要画个小图了:
- JWT不需要在服务端保存会话信息, 所以它易于应用的扩展;很容易理解,我们后台并没有相应的持久操作、缓存操作,那么扩展起来岂不是嗨翻天。
从特点中找缺点
- 一旦成功签发JWT token,无法手动将其过期;因为我们的服务器并没有存储相应的状态,而token却是一个字符串,因此只能等待token失效,除非服务器部署额外的逻辑。 也就是说一个用户在手机A中登录了,然后又在手机B中登录,在过期之前手机A和B都可以登录,无法做到B登录后让A过期,如果要做到这点,就必须让服务器维护一个清单(记录该账号是否已经签发token),这样又回到session的老路了
- 在token签发后的有效时间内,JWT无法做到及时获取最新数据,例如修改密码后无感知; 修改密码我们也无法操作token。
- 存储空间、网络流量开销更大; 例如abcdef存到cookie占6字节,但是存储到JWT需要几百字节甚至更多。如果说我们的一个月10万次访问量,使用JWT可能要多出几十兆流量,日积月累可就是在烧钱;并且往往我们不只是存储一个id这么简单,因此JWT更不适合存储大量信息。
- 为了安全,JWT需要使用https协议,以免token泄露; 一旦泄露,任何人都可以获得该令牌的所有权限。为了减少盗用,JWT 的有效期应该设置得比较短。
同session形式对比
总结了这么多,也说了不少JWT的缺点,那么下面来说JWT与session的不同之处,以及JWT可代替session的场景。
不同之处
JWT不仅仅是作为身份认证的凭证,还在其payload中存储着会话信息,这是JWT和session的最大的区别。一个在客户端存储会话信息,另一个在服务器存储会话信息。这是session
session机制缺点
1、服务器压力增大,通常session是保存在服务器内存当中的,每个用户的认证信息都会保存在服务器,当用户量增大时,无疑会给服务器带来很大压力
2、存在CSRF跨站请求伪造攻击风险,cookie泄露后有可能被攻击者利用而受到攻击。例如一个人刚刚访问过银行网站,当他无意间进入攻击网站时,网站会在被攻击人不知情情况下,拿到本地的会话信息进行转账操作
3、代码侵入。扩展性不强。在分布式或微服务的系统架构下,需要实现session同步,当我们在新增服务时,还需要同步session到新增的服务。而token不需要靠考虑在哪一台服务器登录了。
4、session基于cookie,app并不支持cookie。并且SPA\APP普遍使用rest api,也就是说后台返回一个json就可以解决问题。
结语
使用JWT实际开发的话推荐使用auth0,并且要解决token刷新的问题来保证用户体验度。
本文总结于: https://blog.csdn.net/qq_41606973/article/details/85220049 http://www.ruanyifeng.com/blog/2018/07/json_web_token-tutorial.html