01
点击登录
打开第三方登录弹窗。
CHAPTER 07
登录状态泳道图
隐去具体产品信息，对比 Firebase Admin session cookie、已有后端认证、客户端 Firebase + Next 胶水层、以及乐观 token 缓存四种登录状态方案。
阅读方式
每张图从左到右看阶段，从上到下看参与方。绿色卡片是实际动作，蓝色箭头是数据交换，灰色点阵是该泳道在此阶段没有动作。
firebase-admin-session-cookie
方案一：Firebase Admin session cookie
官方推荐的 SSR 会话模型：用 ID token 换服务端 httpOnly session cookie。
泳道 / 阶段
01
入口
02
Firebase
03
登录交换
04
会话建立
05
资料聚合
06
首屏恢复
07
后续请求
08
登出/失效
浏览器页面
Firebase Web SDK
02短期 token
完成 OAuth
拿到 currentUser，并临时读取 ID token。
Next 后端
03
接收 ID token
Server Action 或 Route Handler 接收一次性登录交换请求。
05
Set-Cookie
写入 httpOnly / Secure / SameSite cookie，JS 不能读取。
06
SSR 读 cookie
刷新或直达页面时，服务端先验证 cookie 再渲染用户态。
08
清理会话
登出时删除 cookie；敏感场景可检查 revocation。
Firebase Admin/Auth
04Admin SDK
创建 session cookie
校验 ID token，然后生成 Firebase session cookie。
业务后端
07
读取业务资料
服务端拿 uid 向业务后端查询 profile、权限、余额等。
判断
适合 Next 首屏就要可信识别用户的应用，但不能自动替代业务后端的登录逻辑。
- 最快获得可信 SSR 登录态。
- cookie 是新的 session，不是把 ID token 原样存 cookie。
- 如果已有业务登录接口，仍要继续调用它，否则会绕过业务副作用。
existing-backend-admin-sdk
方案二：现有后端已经实现 Firebase Admin SDK
认证、用户同步、业务 session 都由现有后端完成；Next 不另建 Firebase 会话。
泳道 / 阶段
01
入口
02
Firebase
03
登录交换
04
会话建立
05
资料聚合
06
首屏恢复
07
后续请求
08
登出/失效
浏览器页面
01
点击登录
页面只负责启动 Firebase 登录。
Firebase Web SDK
02
返回 ID token
浏览器拿 token，用于调用现有登录接口。
现有业务后端
03不能跳过
执行现有登录接口
接收 ID token，开始业务登录流水线。
05
同步业务用户
创建用户、更新昵称头像、会员/权限、埋点、设备信息等。
06
返回 profile/session
可设置业务 session cookie，也可返回业务 profile。
08
统一登出
调用现有登出接口，清业务 cookie 和后端 session。
Firebase Admin/Auth
04
后端校验身份
现有后端用 Admin SDK 校验 token，必要时签发 custom token。
Next 后端
07
只做胶水
SSR 或 API 需要登录态时，代理/复用现有业务 session。
判断
适合已有完整登录后端的项目。Next 应复用它，而不是平行重做一套认证。
- 业务后端拥有认证事实和业务副作用。
- Next 自建 Firebase Admin session 会形成第二套会话源。
- 最佳做法是让 Next 复用现有后端 session 或只做代理。
compromise-forward-token
方案三：折中方案，客户端 Firebase 是唯一 token 来源
Next 只转发 token；Zustand persist 只缓存头像昵称；全局 Bootstrapper 恢复真实 profile。
泳道 / 阶段
01
入口
02
Firebase
03
登录交换
04
会话建立
05
资料聚合
06
首屏恢复
07
后续请求
08
登出/失效
浏览器页面
02
先显示 cached 用户
全局 AuthBootstrapper 标记 restoring，减少 Guest 闪烁。
08
请求时再取 token
每次敏感请求从 Firebase helper 取实时 token，登出清缓存。
Zustand persist
01非权限依据
读取展示缓存
只缓存 uid、头像、昵称、展示偏好，不缓存 ID token。
07
覆盖缓存
写入最新 profile；后续页面共享头像昵称和状态。
Firebase Web SDK
03
恢复 currentUser
Firebase 客户端恢复真实登录态，并按需读取新 ID token。
Next SA / Route
04
只转发请求
Server Action / Route Handler 带 ID token 转发给业务后端。
06
返回标准 profile
Next 只做字段归一化，不保存 Firebase Admin session。
业务后端
05
后端校验并聚合
现有后端继续执行 Firebase 校验和用户资料逻辑。
判断
适合学习 demo 和迁移过渡：恢复观感接近客户端应用，同时不绕过现有后端。
- 恢复速度靠展示缓存，真实权限靠后端校验。
- 不会把 ID token 放进 Zustand/localStorage。
- 不会跳过现有业务后端的登录、同步、登出逻辑。
optimistic-zustand-id-token
方案四：乐观 token 缓存，失败后被动续期
Zustand persist 同时缓存展示资料、短期 ID token 和过期时间；读请求先用缓存，401 后再让 Firebase 强制刷新并重试一次。
泳道 / 阶段
01
入口
02
Firebase
03
登录交换
04
会话建立
05
资料聚合
06
首屏恢复
07
后续请求
08
登出/失效
浏览器页面
02
立即显示用户态
头像昵称先展示；低风险读请求可先带 cached token 发出。
08
续不上则登出
刷新失败或无 currentUser 时清空缓存，页面回到匿名态。
Zustand persist
01短期 bearer
恢复缓存包
读取 profile、cached ID token、tokenExp；不保存 refresh token。
07
覆盖新状态
成功后写入新 token、tokenExp、profile，后续页面共享。
Firebase Web SDK
05
401 后强刷
如果过期或失效，singleflight 调 currentUser.getIdToken(true)。
Next SA / Route
03
转发 cached token
Next 不校验、不落库，只把 token 放进后端请求头。
06
fresh token 重试
同一个请求只自动重试一次，避免无限循环。
业务后端
04
后端校验 token
业务后端继续用 Admin SDK 校验身份和权限。
判断
这是体验最快的客户端方案，但边界必须收紧：token 不是秘密，后端仍是唯一权限裁判，敏感写操作不要只信缓存 token。
- 用户体验最好：视觉状态和读请求都能最快启动。
- 风险边界更高：XSS、浏览器扩展、DevTools 都可能看到 token。
- 只适合后端严格校验、客户端请求层统一重试、敏感写操作等待 fresh token 的项目。