关于token过期的问题
来源:11-9 【登录页面】SignIn登录业务处理

慕函数2082699
2021-10-06
想请教一下,token过期的处理方式,一般是在前端处理,还是后端处理:
1、前端处理,那是每次用到私有路由的时候,验证token有效?过期的话向后端重新发起login请求?还是后端重新给一个过期token更新的接口?
2、后端处理,每次向后端发起情况都带token,后端理论上是可以判断token过期的,但是这有个问题,就是前端私有路由的时候因为不看token过期,那就通过了,但是后端检验过期并且可能重新生成token因为种种原因不成功,倒是页面路由通过了,但是页面数据都获取失败?还有一个问题就是假设后端重新生成token,前端如何触发更新
感觉前端或者后端处理都有那么点问题,想请假下比较主流的做法是什么?
1回答
-
阿莱克斯刘
2021-10-15
hello 同学你好。
token过期的处理方式,一般是在前端处理,还是后端处理?
要看你用的是什么验证方式,如果是无状态(如jwt),那么前端可以校验是否过期,当然后端也可以校验。但如果是session,那么token的过期处理一定是放在后端验证的。
前端处理,那是每次用到私有路由的时候,验证token有效?
是的,需要检查一下(课程没有处理这个过程)
过期的话向后端重新发起login请求?
是的,过期的话需要阻止用户访问私有页面,同时把用户重定向到登录页面,并且清空用户数据(可选)。
还是后端重新给一个过期token更新的接口?
一般来说oAuth2标准下会有3种token:access_token,id_token,refresh_token。
access_token就是基于session的token(短效)
id_token就是jwttoken(短效)
refresh_token(长效),使用这个长效token可以用户更新短效token
也有的公司只提供一个session token或id_token长期使用,快过期的时候使用同一个token置换新token,这种方式不太安全
后端处理,每次向后端发起情况都带token,后端理论上是可以判断token过期的,但是这有个问题,就是前端私有路由的时候因为不看token过期,那就通过了,但是后端检验过期并且可能重新生成token因为种种原因不成功,倒是页面路由通过了,但是页面数据都获取失败
你说的没错,实际上每次api请求都需要带上token,但是后端需要校验的绝对不是简单的判断token是否过期这么简单。后端还会校验token的真伪,还会通过token来检查你是否有权限访问当前数据库的资源等等。
不管前端有没有检查token过期,后端都一定会对token的过期做二次验证。前端做token过期的检查的好处是可以减少发送api请求的频率,降低后端压力(只要token过期前端就不需要发api请求了)。
前端的页面路由也是同样的道理,使用jwt的话前端可以自行判断,没必要非要等后端返回401以后在做登录页面重定向。但如果使用session就得等后端返回401然后再进行登录页面重定向
假设后端重新生成token,前端如何触发更新
可以使用refresh_token来置换过期的token。
以上的答案都是比较主流的处理方式。
20
相似问题