如何创建永不过期的Firebase Auth自定义令牌？

首先得明确：Firebase官方自定义令牌确实不支持设置超过1小时的有效期，这是平台为了安全做出的硬性限制——短期令牌能最大程度降低泄露后的风险。不过针对你用它做API Bearer认证的场景，有几个可行的替代方案，既能贴合Firebase Auth生态，又能解决有效期过短的问题：

1. 实现自动令牌刷新（推荐，合规且安全） #

这是最符合Firebase设计理念的方案，核心是利用Firebase的**刷新令牌（Refresh Token）**来自动获取新的认证凭证，对用户完全透明：

• 客户端流程：用户首次登录后，除了自定义令牌，还会拿到Firebase的刷新令牌（这个令牌长期有效，除非用户主动注销、账号被禁用，或者令牌被手动撤销）。在自定义令牌过期前（比如提前5分钟），客户端调用Firebase Auth的刷新接口，用刷新令牌换取新的自定义令牌。
• 后端配合：如果你的API需要验证自定义令牌，后端可以接收客户端传来的刷新令牌，先用Firebase Admin SDK验证刷新令牌的有效性，然后为该用户生成新的自定义令牌返回给客户端。
• 优势：完全遵循Firebase安全规范，令牌泄露后的风险窗口短，且能自动维持用户登录状态，不会影响业务流程。

2. 改用Firebase ID令牌作为API凭证 #

如果你的API不需要自定义令牌里的额外自定义Claims，直接用Firebase ID令牌替代也是个好选择：

• ID令牌同样是1小时有效期，但客户端可以通过刷新令牌自动刷新，Firebase SDK已经封装了这个逻辑（比如Web端的firebase.auth().currentUser.getIdToken(true)可以强制刷新）。
• 后端用Firebase Admin SDK的verifyIdToken()方法验证令牌，既简单又安全，不需要自己处理自定义令牌的生成逻辑。

3. 自定义长期JWT（不推荐，需承担安全风险） #

如果非要追求“永不过期”的令牌，你可以基于Firebase Auth的用户身份，自己生成独立的JWT：

• 流程：用户首次通过Firebase认证后，后端用Admin SDK验证用户的身份凭证（自定义令牌或ID令牌），确认用户合法后，生成自己的JWT，设置极长的有效期（比如10年），并包含必要的用户信息。
• 风险提示：这种方式完全脱离Firebase的令牌生命周期管理，一旦令牌泄露，攻击者可以长期访问你的API，除非你维护一个令牌黑名单系统来撤销泄露的令牌。另外，这也不符合OAuth2/JWT的安全最佳实践，谨慎使用。

最后提醒下：Firebase的短期令牌限制是出于安全考量，尽量优先选择前两种方案，既能满足业务需求，又能保证系统安全。

内容的提问来源于stack exchange，提问作者melchoir55