2017-07-06 82 views
1

看起来像Firebase,当他们从v2迁移到v3.x SDK(现在变成v4)时,决定删除自动会话过期选项,以支持始终通过身份验证的模型。Firebase会话过期

这是一个很好的功能提供,但是从网络安全的角度来看,我看到了一些问题,因为这是唯一的选项的火力地堡的SDK与Firebase-生成的令牌,如email and password authentication(其中一些在链接的谷歌小组讨论中有很好的解释)。

在页面退出时通常提供的调用user.signOut()的建议有一些漏洞。也就是说,如果客户端崩溃,那么这个代码就不会执行,因此这个策略就会崩溃。在“上登出页面加载”的建议也有孔在它:

  1. 强制所有用户每次登录的时候页面加载/重载(不是目标)
  2. 作为火力地堡推动大多数都到客户端有什么能够阻止某人创建试图访问一个有针对性的火力地堡一个脚本,而不具有user.signOut()

我正在寻找一个战略,做一个更好的工作,从网络安全的角度,允许用户如果愿意的话可以选择“永久认证”策略选择,而不是默认(即用“记住我”按钮)。我想出了

一种策略是如下:

    1. 用户登录获取生成JWT该会议,并把它写到火力
    2. 如果用户没有选择“记住我“在登录时设置了一个onDisconnect处理程序,该处理程序从该用户令牌的列表中清除令牌
    3. 在Firebase安全规则中,确保发出请求的用户的JWT位于该用户的令牌列表中

    这样感觉更安全,因为即使浏览器崩溃,onDisconnect方法仍会执行。 但是,JWT不可用作Firebase规则变量(only the contents of the token)!

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

  • 回答

    2

    这是一个建议: 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。

    不知道这是否会减轻你的问题,但火力地堡正在考虑以下特点:

    1. 到Web认证指定持久性的能力。这与在Firebase 3.x中sessionOnly auth的工作方式类似。这将使“记住我”功能易于实现。
    2. 撤销会话的能力。
    +0

    嘿@bojeil,谢谢你的建议。我认为在多租户方案中存在一些边缘案例(用户可能会通过更新'auth_time'在不知不觉中“扩展”登录到同一帐户的其他用户的会话),但这是一个体面的解决方案。这些其他功能的任何时间表? :) – MandM

    +0

    您是指“用户可能无意中”通过更新auth_time扩展“登录到同一帐户的其他用户的会话”。 auth_time仅在重新认证或登录时更新。目前没有针对这些功能的可靠时间表。 – bojeil

    +0

    我写了关于用户A和用户B从不同机器登录的完整解释,一个基本上更新另一个机器的'auth_time',但后来意识到我很愚蠢,因为'auth_time'不是共享的,因为它是一个部分的个人智威汤逊。谢谢!要考虑的另一个功能是允许通过电子邮件和密码身份验证来定制JWT声明定义,而不是要求单独的服务器。 – MandM