为何使用Firebase会话令牌而非直接使用JWT身份验证令牌？

API 探路者

2026-7-27

Firebase会话Cookie vs 请求体传递JWT的利弊分析

当然可以不用实现会话Cookie功能，直接通过auth.currentUser.getIdToken()获取JWT令牌，在请求体（或请求头）中传递给后端，再用Firebase Admin SDK验证身份——这种方案在很多简单场景下完全可行，但和使用会话Cookie相比，会存在以下几个明显弊端：

前端重复工作量大：每次发起需要授权的请求时，都得手动调用getIdToken()获取令牌，再把它塞进请求体或请求头里。如果页面中有大量接口请求，很容易遗漏，而且还要额外处理令牌过期的情况：得监听令牌过期事件，自动刷新后重试请求，不然用户会莫名收到权限错误提示。
安全性短板：把JWT放在请求体或普通请求头中，很容易被XSS攻击窃取到。而HTTP-only类型的会话Cookie是前端JS无法访问的，能有效规避这类风险，尤其是页面中引入第三方脚本时，安全性差距会更突出。
适配SSR场景困难：如果你的应用是服务端渲染（比如Next.js SSR、Nuxt SSR），前端还没初始化Firebase Auth时，服务端需要提前拿到用户身份来渲染页面内容。这时候没法通过前端getIdToken()获取令牌，而会话Cookie会随HTTP请求自动携带，服务端直接读取就能完成验证，更适配SSR的运行流程。
会话生命周期管理繁琐：Firebase ID Token默认有效期只有1小时，虽然可以刷新，但如果想让用户保持登录状态更久（比如7天），手动管理刷新逻辑很容易出错。而会话Cookie可以设置更长的有效期，并且后端能主动撤销指定会话，管理起来更灵活。
不符合通用API规范：行业通用的身份凭证传递方式是放在Authorization请求头中（格式如Bearer <token>），而非请求体。如果放在请求体，每次请求都要额外处理这个字段，和常规RESTful API设计不一致，后续维护或其他开发者接手时容易产生困惑。