前后端分离的项目中采用jwt作为接口的安全机制会遇到jwt过期的问题。
jwt中可以设置过期时间，即使是设置成一个月，但可能用户正上一秒还在使用，下一秒jwt过期被叫去重新登录，这是不能接受的，所以需要有处理jwt过期的机制。
在这个问题上比较常用的做法是采用双token——access token和refresh token来处理，access token用户授权，refresh token用于前者过期后获取新的access token。
这里。
我在这里记录我单token方案的思路。

• 用户登录时生成token并设置过期时间（这里可以设置一个较短的时间，如30分钟），将这个token返回并在下一次请求中携带以用来认证。同时我们在redis中保存该token的刷新标记，key为"jwt_token:userId"，value为生成的token，并设置过期时间（这里可以设置一个较长的时间，如7天，作为用户最大未使用时长，超过就需要重新登录）。
• 后端接收前端请求，如果携带的token未过期，则正常访问。
• 后端接收前端请求，如果携带的token过期，则拒绝访问并返回一个jwt过期异常。
• 前端知晓token过期后需要携带过期的token访问token刷新接口，后端查询redis，1）value与token相同：生成新的token，覆盖value，并刷新value的过期时间，返回前端；2）value与token不相同，拒绝刷新，用户重新登录；3）key不存在，拒绝刷新，用户重新登录。
• 用户重新登录时，生成新的token，并把redis中的相应记录覆盖，用户注销时将redis中的记录删除，旧的token将会在较短的时间后过期且不能刷新。

相较于双token的方案，单token方法既是access token又是refresh token，这样的好处是对于前端无感，前端只需要管理token，过期后带着过期的token重新获取。redis中维护的过期时间即是用户多久没使用必须登录的时间。

这个方法还有改进的空间，如在key中加入设备号字段，这样就可以方式多设备登录的覆盖问题，也可以手动控制不同设备上的注销。

可能有考虑不周的地方，还望指教。