JWT实践总结篇（一）

近期使用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
转载，引用请声明出处哦