JWT生成token及过期处理方案

## 业务场景

在前后分离场景下,越来越多的项目使用token作为接口的安全机制,APP端或者WEB端(使用VUE、REACTJS等构建)使用token与后端接口交互,以达到安全的目的。本文结合stackoverflow以及本身项目实践,试图总结出一个通用的,可落地的方案。

## 基本思路

- 单个token

1. token(A)过期设置为15分钟

2. 前端发起请求,后端验证token(A)是否过期;如果过期,前端发起刷新token请求,后端设置已再次授权标记为true,请求成功

3. 前端发起请求,后端验证再次授权标记,如果已经再次授权,则拒绝刷新token的请求,请求成功

4. 如果前端每隔72小时,必须重新登录,后端检查用户最后一次登录日期,如超过72小时,则拒绝刷新token的请求,请求失败

- 授权token加上刷新token

用户仅登录一次,用户改变密码,则废除token,重新登录

## 1.0实现

1.登录成功,返回access\_token和refresh\_token,客户端缓存此两种token; 

2.使用access_token请求接口资源,成功则调用成功;如果token超时,客户端 

携带refresh\_token调用中间件接口获取新的access\_token; 

3.中间件接受刷新token的请求后,检查refresh_token是否过期。 

如过期,拒绝刷新,客户端收到该状态后,跳转到登录页; 

如未过期,生成新的access\_token和refresh\_token并返回给客户端(如有可能,让旧的refresh\_token失效),客户端携带新的access\_token重新调用上面的资源接口。 

4.客户端退出登录或修改密码后,调用中间件注销旧的token(使access\_token和refresh\_token失效),同时清空客户端的access\_token和refresh\_toke。

后端表 

id user\_id client\_id client\_secret refresh\_token expire\_in create\_date del_flag

## 2.0实现

场景: access\_token访问资源 refresh\_token授权访问 设置固定时间X必须重新登录

1.登录成功,后台jwt生成access\_token(jwt有效期30分钟)和refresh\_token(jwt有效期15天),并缓存到redis(hash-key为token,sub-key为手机号,value为设备唯一编号(根据手机号码,可以人工废除全部token,也可以根据sub-key,废除部分设备的token。),设置过期时间为1个月,保证最终所有token都能删除),返回后,客户端缓存此两种token; 

2.使用access\_token请求接口资源,校验成功且redis中存在该access\_token(未废除)则调用成功;如果token超时,中间件删除access\_token(废除);客户端再次携带refresh\_token调用中间件接口获取新的access_token; 

3.中间件接受刷新token的请求后,检查refresh_token是否过期。 

如过期,拒绝刷新,删除refresh_token(废除); 客户端收到该状态后,跳转到登录页; 

如未过期,检查缓存中是否有refresh\_token(是否被废除),如果有,则生成新的access\_token并返回给客户端,客户端接着携带新的access_token重新调用上面的资源接口。 

4.客户端退出登录或修改密码后,调用中间件注销旧的token(中间件删除access\_token和refresh\_token(废除)),同时清空客户端侧的access\_token和refresh\_toke。 

5.如手机丢失,可以根据手机号人工废除指定用户设备关联的token。 

6.以上3刷新access_token可以增加根据登录时间判断最长X时间必须重新登录,此时则拒绝刷新token。(拒绝的场景:失效,长时间未登录,频繁刷新)

2.0 变动 

1.登录 

2.登录拦截器 

3.增加刷新access_token接口 

4.退出登录 

5.修改密码

## 3.0实现

场景:自动续期 长时间未使用需重新登录

1.登录成功,后台jwt生成access\_token(jwt有效期30分钟),并缓存到redis(hash-key为access\_token,sub-key为手机号,value为设备唯一编号(根据手机号码,可以人工废除全部token),设置access_token过期时间为7天,保证最终所有token都能删除),返回后,客户端缓存此token;

2.使用access\_token请求接口资源,校验成功且redis中存在该access\_token(未废除)则调用成功;如果token超时,中间件删除access\_token(废除),同时生成新的access\_token并返回。客户端收到新的access_token, 

再次请求接口资源。

3.客户端退出登录或修改密码后,调用中间件注销旧的token(中间件删除access\_token(废除)),同时清空客户端侧的access\_token。

4.以上2 可以增加根据登录时间判断最长X时间必须重新登录,此时则拒绝刷新token。(拒绝的场景:长时间未登录,频繁刷新)

5.如手机丢失,可以根据手机号人工废除指定用户设备关联的token。

3.0 变动

1.登录 

2.登录拦截器 

3.退出登录 

4.修改密码

1.3 场景:token过期重新登录 长时间未使用需重新登录

1.登录成功,后台jwt生成access\_token(jwt有效期7天),并缓存到redis,key为 "user\_id:access\_token",value为access\_token(根据用户id,可以人工废除指定用户全部token),设置缓存过期时间为7天,保证最终所有token都能删除,请求返回后,客户端缓存此access_token;

2.使用access\_token请求接口资源,校验成功且redis中存在该access\_token(未废除)则调用成功;如果token超时,中间件删除access\_token(废除),同时生成新的access\_token并返回。客户端收到新的access_token, 

再次请求接口资源。

3.客户端退出登录或修改密码后,调用中间件注销旧的token(中间件删除access\_token(废除)),同时清空客户端侧的access\_token。

4.以上2 可以增加根据登录时间判断最长X时间必须重新登录,此时则拒绝刷新token。(拒绝的场景:长时间未登录,频繁刷新)

5.如手机丢失,可以根据手机号人工废除指定用户设备关联的token。

1.3 变动

1.登录 

2.登录拦截器 

3.退出登录 

4.修改密码

# 解决方案

2.0 场景: access\_token访问资源 refresh\_token授权访问 设置固定时间X必须重新登录

1.登录成功,后台jwt生成access\_token(jwt有效期30分钟)和refresh\_token(jwt有效期15天),并缓

存到redis(hash-key为token,sub-key为手机号,value为设备唯一编号(根据手机号码,可以人工废除全

部token,也可以根据sub-key,废除部分设备的token。),设置过期时间为1个月,保证最终所有token都

能删除),返回后,客户端缓存此两种token;

2.使用access\_token请求接口资源,校验成功且redis中存在该access\_token(未废除)则调用成功;如果

token超时,中间件删除access\_token(废除);客户端再次携带refresh\_token调用中间件接口获取新的

access_token;

3.中间件接受刷新token的请求后,检查refresh_token是否过期。

如过期,拒绝刷新,删除refresh_token(废除); 客户端收到该状态后,跳转到登录页;

如未过期,检查缓存中是否有refresh\_token(是否被废除),如果有,则生成新的access\_token并返回给

客户端,客户端接着携带新的access_token重新调用上面的资源接口。

4.客户端退出登录或修改密码后,调用中间件注销旧的token(中间件删除access\_token和refresh\_token(

废除)),同时清空客户端侧的access\_token和refresh\_toke。

5.如手机丢失,可以根据手机号人工废除指定用户设备关联的token。

6.以上3刷新access_token可以增加根据登录时间判断最长X时间必须重新登录,此时则拒绝刷新token。(

拒绝的场景:失效,长时间未登录,频繁刷新)

2.0 变动

1.登录

2.登录拦截器

3.增加刷新access_token接口

4.退出登录

5.修改密码

3.0 场景:自动续期 长时间未使用需重新登录

1.登录成功,后台jwt生成access_token(jwt有效期30分钟),并缓存到redis(hash-key为

access_token,sub-key为手机号,value为设备唯一编号(根据手机号码,可以人工废除全部token,也可以

根据sub-key,废除部分设备的token。),设置access_token过期时间为1个月,保证最终所有token都能删

除),返回后,客户端缓存此token;

2.使用access\_token请求接口资源,校验成功且redis中存在该access\_token(未废除)则调用成功;如果

token超时,中间件删除access\_token(废除),同时生成新的access\_token并返回。客户端收到新的

access_token,

再次请求接口资源。

3.客户端退出登录或修改密码后,调用中间件注销旧的token(中间件删除access_token(废除)),同时清

空客户端侧的access_token。

4.以上2 可以增加根据登录时间判断最长X时间必须重新登录,此时则拒绝刷新token。(拒绝的场景:长

时间未登录,频繁刷新)

5.如手机丢失,可以根据手机号人工废除指定用户设备关联的token。

3.0 变动

1.登录

2.登录拦截器

3.退出登录

4.修改密码

4.0 场景:token过期重新登录 长时间未使用需重新登录

1.登录成功,后台jwt生成access_token(jwt有效期7天),并缓存到redis,key为

"user\_id:access\_token" + 用户id,value为access_token(根据用户id,可以人工废除指定用户全部

token),设置缓存过期时间为7天,保证最终所有token都能删除,请求返回后,客户端缓存此

access_token;

2.使用access\_token请求接口资源,校验成功且redis中存在该access\_token(未废除)则调用成功;如果

token超时,中间件删除access\_token(废除),同时生成新的access\_token并返回。客户端收到新的

access_token,

再次请求接口资源。

3.客户端退出登录或修改密码后,调用中间件注销旧的token(中间件删除access_token(废除)),同时清

空客户端侧的access_token。

4.以上2 可以增加根据登录时间判断最长X时间必须重新登录,此时则拒绝刷新token。(拒绝的场景:长

时间未登录,频繁刷新)

5.如手机丢失,可以根据手机号人工废除指定用户设备关联的token。

4.0 变动

1.登录

2.登录拦截器

3.退出登录

4.修改密码

## 最终实现

### 后端

1. 在登录接口中 如果校验账号密码成功 则根据用户id和用户类型创建jwt token(有效期设置为-1,即永不过期),得到A

2. 更新登录日期(当前时间new Date()即可)(业务上可选),得到B

3. 在redis中缓存key为ACCESS_TOKEN:userId:A(加上A是为了防止用户多个客户端登录 造成token覆盖),value为B的毫秒数(转换成字符串类型),过期时间为7天(7 * 24 * 60 * 60)

4. 在登录结果中返回json格式为{"result":"success","token": A}

5. 用户在接口请求header中携带token进行登录,后端在所有接口前置拦截器进行拦截,作用是解析token 拿到userId和用户类型(用户调用业务接口只需要传token即可),

如果解析失败(抛出SignatureException),则返回json(code = 0 ,info= Token验证不通过, errorCode = '1001');

此外如果解析成功,验证redis中key为ACCESS_TOKEN:userId:A 是否存在 如果不存在 则返回json(code = 0 ,info= 会话过期请重新登录, errorCode = '1002');

如果缓存key存在,则自动续7天超时时间(value不变),实现频繁登录用户免登陆。

6. 把userId和用户类型放入request参数中 接口方法中可以直接拿到登录用户信息

7. 如果是修改密码或退出登录 则废除access_tokens(删除key)

### 前端(VUE)

1. 用户登录成功,则把username存入cookie中,key为loginUser;把token存入cookie中,key为accessToken

  把token存入Vuex全局状态中

2. 进入首页

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,362评论 5 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,330评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,247评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,560评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,580评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,569评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,929评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,587评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,840评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,596评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,678评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,366评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,945评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,929评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,165评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 43,271评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,403评论 2 342

推荐阅读更多精彩内容