发布于2026-06-30 阅读(0)
扫一扫,手机访问
大家日常开发中对 Token 应该不陌生,这东西最常见的就是两个用途:阻止表单重复提交,以及做身份验证。具体怎么用,不妨先拆开看看。
防止重复提交这件事,通常得前后端一起上。比如前端点完提交按钮,立马把按钮置灰,不让再点;同时客户端和服务端各自存一份 token,客户端扔在 Cookie 或表单隐藏域里,服务端存在 Session 或其他缓存里。两边配合,基本就能把重复提交堵死。
身份验证的流程大致是这样:客户端拿用户名和密码请求登录,通过 Ajax 发给后端;服务端收到后验证用户名密码,验证通过就签发一个 Token 返回给客户端;客户端收到 Token 后存起来,可以放 Cookie 或者 Local Storage 里;之后每次请求资源,都得带着这个 Token,服务端收到请求后验证 Token 的有效性,验证通过才返回数据。
Token 过期,说起来就是身份凭证到了有效期,需要用户重新验证身份,或者用刷新 Token 换一个新的访问 Token。
这种情况一般在几个场景里出现:
处理 Token 过期,常见的方法有:
JWT Token 的 payload 部分是个 JSON 串,用来传递一组声明,JWT 标准里定义了这几个标准声明:
iss(Issuer):JWT 的签发主体sub(Subject):JWT 的所有者aud(Audience):JWT 的接收对象exp(Expiration time):JWT 的过期时间nbf(Not Before):JWT 的生效开始时间iat(Issued at):JWT 的签发时间jti(JWT ID):JWT 的唯一标识除了标准声明,我们也可以自定义声明。拿 com.auth0 举个例子,下面这段代码就能生成一个带过期时间的 Token:
String token = JWT.create()
.withIssuer(ISSUER)
.withIssuedAt(new Date(currentTime))// 签发时间
.withExpiresAt(new Date(currentTime + EXPIRES_IN * 1000 * 60))// 过期时间戳
.withClaim("username", username)//自定义参数
.sign(Algorithm.HMAC256(user.getPassword()));
这里每个方法的作用也清楚:withIssuer() 设置签发主体,withIssuedAt() 设置签发时间,withExpiresAt() 设置过期时间戳,过期时长由 EXPIRES_IN(单位秒)控制,withClaim() 用来加自定义参数。
JWT 设了过期时间之后,一旦超时,接口就调不通了,用户得重新登录拿新 Token。如果每次过期都要用户重新登录,体验肯定不好,所以很多应用会采用 Token 过期后自动续期的方案,只在特定条件下才让用户重新登录。
Token 续期的方案有好几种,挑几个有代表性的聊聊。先看一个单 Token 方案,这个方案不光能续期,还能在某些条件下强制用户重新登录。

另外,后端也可以记录刷新 Token 的次数,比如上限设成 50 次,达到之后就不允许再刷新了,必须重新授权。
单 Token 方案原理简单,接下来再看一个双 Token 方案。
access_token 和 refresh_token,客户端把两个 Token 都缓存起来;access_token 请求接口资源,成功就正常返回;如果 Token 超时,客户端就带上 refresh_token 去调刷新接口,换一个新的 access_token;refresh_token 是否过期。如果过期了,就拒绝刷新,客户端收到后跳转到登录页;如果没过期,就生成新的 access_token 返回给客户端;access_token 重新调之前的资源接口;access_token 和 refresh_token 都失效,同时清空客户端缓存的这两个 Token。微信网页授权就是基于 OAuth2.0 机制实现的,用的也是双 Token 方案。

微信网页授权的流程是这样的:
除了这些,后端也可以用 Redis 来存储 Token,直接设置键值对的过期时间。如果 Redis 里查不到对应的 Token 记录,就说明 Token 已经过期了。
以上就是 Token 过期实现自动续期的几种常见方法,从单 Token 到双 Token,再到微信的实践方案,基本覆盖了日常开发中的主要场景。
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
正版软件
正版软件
正版软件
正版软件
正版软件
1
2
3
7
8