Firebase刷新令牌到期 [英] Firebase refresh-token expiration

问题描述

在使用Firebase的REST API测试我们产品之一的Web应用程序的安全性时，当我们意识到在Firebase实现的V3中刷新令牌永不过期时，我们感到惊讶，允许任何刷新令牌永久创建新令牌.

尽管今天本地存储似乎是一个相当安全的解决方案，但我们担心明天存储可能会失败，即使是很短的时间，我们也无法阻止某人使用任何存储这些刷新令牌.

两因素身份验证将有助于缓解此问题，但第一步仍会受到影响.

是否可以通过Firebase将令牌或类似行为列入黑名单，而无需自己处理所有令牌交换(例如铸造)?在阅读文档时，我们找不到此类功能. /p>

任何建议表示赞赏.

解决方案

Firebase最近实现了尽管这不会让您杀死无效的JWT，但确实可以防止刷新令牌(至少从到目前为止的测试来看)，并且它允许在Firebase数据库内部进行更清晰的控制流.

请参阅管理员管理会话"中的大致示例

While testing the security of one of our product, a web application, using the REST API of Firebase we got surprised when we realised that refresh-tokens never expire in the V3 of the Firebase implementation, allowing any refresh-token to create new tokens forever.

While local-storage seem a reasonably safe solution today, we are concerned by the possibility that it could fail tomorrow, even for a short amount of time, and that we cannot stop someone from using any of these refresh-tokens.

Two factor authentication will help mitigate the issue, but the first step would become compromised nonetheless.

Is there a way to blacklist tokens, or similar behaviour, with Firebase, without handling all tokens exchange, such as minting, ourselves? We could not find such feature when going through the doc.

Any advice appreciated.

解决方案

Firebase recently implemented revokeRefreshTokens() inside the admin sdk. Although this will not let you kill an invalid JWT, it does allow you to prevent a refresh of the token (from my testing so far at least) and it allows cleaner control flow inside firebase database.

See Admin Manage Sessions For rough examples

这篇关于Firebase刷新令牌到期的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！