Firebase会话到期

Man*_*ndM 7 session firebase firebase-authentication

它看起来像Firebase,当他们从v2移动到v3.x SDK(现在进入v4)时,决定删除自动会话到期的选项,转而使用经过身份验证的模型.

这是一个很好的功能,但从网络安全的角度来看,我发现了一些问题,因为这是使用Firebase生成的令牌(例如电子邮件和密码身份验证)的Firebase SDK 的唯一选项(其中一些在链接的Google中得到了很好的解释)小组讨论).

user.signOut()在页面退出时调用的常见建议有一些漏洞.也就是说,如果客户端崩溃,那么这个代码永远不会被执行,因此策略就会崩溃."登出页面加载"建议也有漏洞:

  1. 每次页面加载/重新加载(而不是目标)时强制所有用户登录
  2. 由于Firebase将大部分内容推送到客户端,因此没有任何内容可以阻止某人创建尝试访问目标Firebase的脚本无需user.signOut()

我正在寻找一种更好的工作策略,从网络安全的角度来看,允许用户选择"经常认证"的策略,如果他/她选择的话,而不是默认的(即使用"记住我"按钮).

我想出的一个策略如下:

  1. 用户登录
  2. 获取该会话生成的JWT并将其写入Firebase
  3. 如果用户在登录时未选择"记住我",请设置一个onDisconnect处理程序,该处理程序从该用户令牌列表中清除该令牌
  4. 在Firebase安全规则中,确保发出请求的用户的JWT位于该用户的令牌列表中

这感觉更安全,因为onDisconnect即使浏览器崩溃,该方法仍将执行.但是,JWT不能用作Firebase规则变量(只有令牌的内容)!

鉴于这些问题/有缺陷的方法,如何在浏览器使用Firebase生成的令牌关闭/崩溃(甚至在预定的一段时间后)后使会话无效?

boj*_*eil 5

这是一个建议:ID令牌有一个auth_time字段.这是用户进行身份验证的时间,您可以强制执行所需的任何会话长度.如果您使用https://firebase.google.com/docs/reference/security/database/#now和auth.token.auth_time 验证服务器上的令牌或数据库规则,则可以强制执行此操作.请访问https://firebase.google.com/docs/reference/security/database/#authtoken.

您需要用户重新验证才能访问数据.重新认证将更新令牌中的auth_time.

这是一种更好的方法,因为跟踪所有ID令牌将无法很好地扩展并且ID令牌在一小时后过期,并且在用户返回应用程序之后将刷新新令牌但将保持相同的auth_time.

不确定这是否会减轻您的顾虑,但Firebase正在研究以下功能:

  1. 为Web身份验证指定持久性的能力.这类似于sessionOnly auth在Firebase 3.x中的工作方式.这将使"记住我"功能易于实现.
  2. 撤消会话的能力.