关于token过期的问题

Question

想请教一下，token过期的处理方式，一般是在前端处理，还是后端处理：
1、前端处理，那是每次用到私有路由的时候，验证token有效？过期的话向后端重新发起login请求？还是后端重新给一个过期token更新的接口？
2、后端处理，每次向后端发起情况都带token，后端理论上是可以判断token过期的，但是这有个问题，就是前端私有路由的时候因为不看token过期，那就通过了，但是后端检验过期并且可能重新生成token因为种种原因不成功，倒是页面路由通过了，但是页面数据都获取失败？还有一个问题就是假设后端重新生成token，前端如何触发更新

感觉前端或者后端处理都有那么点问题，想请假下比较主流的做法是什么？

Answer 1

阿莱克斯刘 2021-10-15 02:16:43

hello 同学你好。

1.  token过期的处理方式，一般是在前端处理，还是后端处理？

   要看你用的是什么验证方式，如果是无状态（如jwt），那么前端可以校验是否过期，当然后端也可以校验。但如果是session，那么token的过期处理一定是放在后端验证的。

2. 前端处理，那是每次用到私有路由的时候，验证token有效？

   是的，需要检查一下（课程没有处理这个过程）

   
   

3. 过期的话向后端重新发起login请求？

   
   

   是的，过期的话需要阻止用户访问私有页面，同时把用户重定向到登录页面，并且清空用户数据（可选）。

4. 还是后端重新给一个过期token更新的接口？

   一般来说oAuth2标准下会有3种token：access_token，id_token，refresh_token。

1. access_token就是基于session的token（短效）

2. id_token就是jwttoken（短效）

3. refresh_token（长效），使用这个长效token可以用户更新短效token

   
   

4. 也有的公司只提供一个session token或id_token长期使用，快过期的时候使用同一个token置换新token，这种方式不太安全

5. 后端处理，每次向后端发起情况都带token，后端理论上是可以判断token过期的，但是这有个问题，就是前端私有路由的时候因为不看token过期，那就通过了，但是后端检验过期并且可能重新生成token因为种种原因不成功，倒是页面路由通过了，但是页面数据都获取失败

   你说的没错，实际上每次api请求都需要带上token，但是后端需要校验的绝对不是简单的判断token是否过期这么简单。后端还会校验token的真伪，还会通过token来检查你是否有权限访问当前数据库的资源等等。

   不管前端有没有检查token过期，后端都一定会对token的过期做二次验证。前端做token过期的检查的好处是可以减少发送api请求的频率，降低后端压力（只要token过期前端就不需要发api请求了）。

   前端的页面路由也是同样的道理，使用jwt的话前端可以自行判断，没必要非要等后端返回401以后在做登录页面重定向。但如果使用session就得等后端返回401然后再进行登录页面重定向

6. 假设后端重新生成token，前端如何触发更新

   可以使用refresh_token来置换过期的token。

以上的答案都是比较主流的处理方式。