「码到三十五」
,同名公众号 :「码到三十五」,wx号 : 「liwu0213」
☠博主专栏 :
♝博主的话 :
搬的每块砖,皆为峰峦之基;公众号搜索「码到三十五」关注这个爱发技术干货的coder,一起筑基
在前后端分离架构中,用户登录成功后,后端颁发JWT token至前端,该token被安全存储于LocalStorage。随后,每次请求均自动携带此token于请求头中,以验证用户身份。后端设有过滤器,拦截并校验token有效性,一旦发现过期则引导用户重新登录。
简单的说明token实现身份认证的步骤:
-
- 用户登录成功服务端返回token
-
- 之后每次用户请求都携带token,在Authorization Header中。
-
- 后端服务取出token进行decode,判断有效期及失效策略。
-
- 返回对应的成功失败
鉴于JWT包含用户信息且需保障安全,其过期时间通常设置较短。然而,这易导致用户频繁登录,尤其是在处理复杂表单时(比如在线考试),因耗时过长而遇token过期,引发不必要的登录中断和数据丢失,严重影响用户体验。如何在用户无感知状态下实现token自动续期的策略,减少频繁登录需求,确保表单数据不丢失?
解决token过期的续期问题可以有很多种不同的方案,这里举一些比较有代表性的例子,一种是单token续期,一种是双token续期。
1 单token续期
-
用户认证与Token生成:用户成功登录后,服务端生成一个包含必要信息的JWT(Json Web Token),并返回给客户端。此Token作为后续请求的身份验证依据。
-
请求携带Token:在后续的每一次API请求中,客户端都需在HTTP请求的
Authorization
头部字段中携带此JWT,以便服务端验证用户的身份和权限。 -
Token管理策略:服务端设定了Token的失效时间(或失效次数)以及一个重新登录的期限阈值。每当用户登录时,服务端会记录当前的登录时间,以便后续验证使用。
-
Token验证与响应:
- 当用户携带Token发起请求时,服务端首先根据Token的失效时间和重新登录期限进行验证。
- 若Token有效,则正常处理请求并返回所需资源。
- 若Token已失效但仍在重新登录期限内,服务端返回特定的错误代码提示Token已过期,同时提示客户端进行Token刷新。
-
Token刷新机制:
- 客户端接收到Token过期错误代码后,自动调用Refresh Token接口,向服务端请求刷新Token。
- 服务端验证请求的有效性(如检查是否仍在重新登录期限内等),通过后生成新的有效Token并返回给客户端。
-
使用刷新后的Token:客户端在收到新的Token后,自动替换掉旧的Token,并在后续的请求中携带此新Token继续访问服务。
-
强制重新登录:
- 若服务端判断当前Token的使用时长已超过了设定的重新登录期限,则不再允许通过Refresh Token接口刷新Token。
- 此时,服务端会返回强制重新登录的错误代码给客户端,客户端接收到此代码后,应引导用户跳转至登录页面进行重新登录。
比如:
- 将 token 过期时间设置为15分钟;
- 前端发起请求,后端验证 token 是否过期;如果过期,前端发起刷新token请求,后端为前端返回一个新的token;
- 前端用新的token发起请求,请求成功;
- 如果要实现每隔72小时,必须重新登录,后端需要记录每次用户的登录时间;用户每次请求时,检查用户最后一次登录日期,如超过72小时,则拒绝刷新token的请求,请求失败,跳转到登录页面。
- 后端还可以记录刷新token的次数,比如最多刷新50次,如果达到50次,则不再允许刷新,需要用户重新授权。
关注公众号[码到三十五]获取更多技术干货 !