Token续期的常见技术方案主要包括以下几种:
-
单Token方案:
- 将Token的过期时间设置为一个合理的值,例如15分钟。
- 当Token过期时,前端发起Token刷新请求,后端生成一个新的Token。
- 可以设置一些条件,如超过72小时或刷新次数超过一定限制后,要求用户重新登录 。
-
双Token方案(推荐):
- 登录成功后,后端生成两个Token:
access_token
(短期有效)和refresh_token
(长期有效)。 - 正常请求使用
access_token
,当access_token
过期时,使用refresh_token
请求新的access_token
。 refresh_token
也可以设置过期时间,并且可以增加额外的安全措施,如刷新次数限制 。
- 登录成功后,后端生成两个Token:
-
Redis存储Token:
- 使用Redis存储Token和过期时间。
- 每次请求时,后端检查Redis中的Token是否存在及是否过期。
- 如果Token过期,则可以使用存储在Redis中的用户信息生成新的Token。
-
JWT Token自动续期:
- 登录成功后,生成JWT Token,并设置较短的过期时间。
- 将Token存储在前端(例如LocalStorage)和后端(例如Redis)。
- 请求时,后端检查Token是否过期,如果过期且满足续期条件,则生成新的Token。
-
拦截器自动续期:
- 在请求拦截器中检查Token是否即将过期。
- 如果即将过期,自动发送续期请求,更新Token。
-
使用滑动窗口:
- 每次用户活动时,更新Token的过期时间,向后滑动窗口。
-
自定义续期逻辑:
- 根据应用需求,可以自定义Token续期的逻辑,例如基于用户行为或特定事件触发续期。
每种方案都有其适用场景,可以根据实际需求和安全要求选择合适的Token续期方案。