JWT 实现登录认证 + Token 自动续期方案！

过去这段时间主要负责了项目中的用户管理模块，用户管理模块会涉及到加密及认证流程，加密已经在前面的文章中介绍了，可以阅读用户管理模块：如何保证用户数据安全。今天就来讲讲认证功能的技术选型及实现。技术上没啥难度当然也没啥挑战，但是对一个原先没写过认证功能的菜鸡甜来说也是一种锻炼吧

技术选型

要实现认证功能，很容易就会想到JWT或者session，但是两者有啥区别？各自的优缺点？应该Pick谁？夺命三连

 

区别

基于session和基于JWT的方式的主要区别就是用户的状态保存的位置，session是保存在服务端的，而JWT是保存在客户端的

认证流程

基于session的认证流程

• 用户在浏览器中输入用户名和密码，服务器通过密码校验后生成一个session并保存到数据库

• 服务器为用户生成一个sessionId，并将具有sesssionId的cookie放置在用户浏览器中，在后续的请求中都将带有这个cookie信息进行访问

• 服务器获取cookie，通过获取cookie中的sessionId查找数据库判断当前请求是否有效

基于JWT的认证流程

• 用户在浏览器中输入用户名和密码，服务器通过密码校验后生成一个token并保存到数据库

• 前端获取到token，存储到cookie或者local storage中，在后续的请求中都将带有这个token信息进行访问

• 服务器获取token值，通过查找数据库判断当前token是否有效

优缺点

• JWT保存在客户端，在分布式环境下不需要做额外工作。而session因为保存在服务端，分布式环境下需要实现多机数据共享

• session一般需要结合Cookie实现认证，所以需要浏览器支持cookie，因此移动端无法使用session认证方案

安全性

• JWT的payload使用的是base64编码的，因此在JWT中不能存储敏感数据。而session的信息是存在服务端的，相对来说更安全

如果在JWT中存储了敏感信息，可以解码出来非常的不安全

性能

• 经过编码之后JWT将非常长，cookie的限制大小一般是4k，cookie很可能放不下，所以JWT一般放在local storage里面。并且用户在系统中的每一次http请求都会把JWT携带在Header里面，HTTP请求的Header可能比Body还要大。而sessionId只是很短的一个字符串，因此使用JWT的HTTP请求比使用session的开销大得多

一次性

无状态是JWT的特点，但也导致了这个问题，JWT是一次性的。想修改里面的内容，就必须签发一个新的JWT

• 无法废弃 一旦签发一个JWT，在到期之前就会始终有效，无法中途废弃。若想废弃，一种常用的处理手段是结合redis