Firebase 如何设置6小时会话有效期并实现免登刷新session cookie

核心需求对齐 #

要落地的会话规则为：

• 用户成功登录后创建总时长6小时的会话，连续6小时无任何操作时自动判定会话失效，重定向回登录页
• 用户持续发起有效请求时，自动重新计算会话的6小时生命周期，不需要用户重复输入登录信息
• 当前已完成的基础实现：通过服务端接口将用户首次登录的idToken兑换为session token，以HttpOnly Cookie形式种到客户端，后续所有服务端请求均通过该Cookie携带的session token完成身份校验，调用内置的verifySessionCookie方法判断会话是否过期，当前卡点为缺少无感知刷新session cookie的实现路径

具体实现步骤 #

1. 设置合理的续期触发阈值 #

不要等session cookie完全过期了再触发刷新，提前设置续期触发临界点：当校验发现当前session cookie的剩余有效时长小于总时长的一半（即3小时）时，自动启动续期流程，避免请求刚好在session失效的临界时间点到达时，出现会话突然中断的问题。
如果剩余有效时长还高于3小时阈值，直接正常放行请求，不做额外处理，减少不必要的接口开销。

2. 无感知续期的核心流程 #

所有受保护路由的前置鉴权逻辑统一做如下处理：

• 从请求携带的Cookie中提取现有session token，调用verifySessionCookie完成有效性校验，同时读取该token的过期时间、关联用户uid信息
• 对比当前系统时间与token过期时间的差值，判断是否达到续期阈值
• 达到续期阈值时，直接使用客户端请求中携带的、由Firebase Auth SDK静默刷新生成的最新有效idToken（该idToken由前端SDK自动维护，过期时会在后台静默刷新，全程不会触发用户重新登录），调用服务端的session cookie生成接口，重新生成一个6小时有效期的新session token
• 将新生成的session token，按照和原cookie完全一致的属性配置（包括HttpOnly、Secure、SameSite、访问路径等）种到响应的Set-Cookie头中，覆盖客户端存储的旧session cookie

3. 常见踩坑规避 #

• 生成新cookie时必须和旧cookie的配置完全一致，否则浏览器会将其识别为两个独立的Cookie，导致续期逻辑失效
• 很多开发者容易在这里踩的坑是，为了实现滑动续期，每次请求都重新生成session cookie，最后导致会话只要用户开着页面就永远不会过期，完全违背了6小时无操作自动登出的设计初衷
• 当检测到请求中携带的idToken已经失效时，不需要跳回登录页，可直接触发前端Firebase SDK的静默刷新逻辑，拿到最新有效idToken后再完成续期，全程用户无感知

边缘场景兼容 #

• 如果verifySessionCookie校验发现session已经完全过期，直接拦截请求重定向到登录页即可
• 校验过程中如果发现会话存在安全异常（比如token被篡改、关联用户被封禁），直接清除客户端的session cookie，引导用户重新登录

内容的提问来源于stack exchange，提问作者Александр Савлевич