使用 Firebase 匿名身份验证作为应用程序中的唯一身份验证方法

Ae *_*pek 3 anonymous-users firebase google-cloud-platform firebase-authentication

我有以下基于 Firebase 后端的移动应用场景:

  • 两个或多个移动应用程序实例通过中央服务(可信)相互通信。这些应用程序通过交换共享密钥进行配对,例如通过扫描二维码或输入配对码。
  • 用户是匿名的,即不需要(或可能)注册。本质上,它是特定设备上的特定应用程序与同上的对应应用程序(相对于用户到用户)配对。
  • 交换的信息是敏感的,但没有内在价值:必须可以相信信息来自给定设备,并且必须可以相信信息已到达预期设备而不是冒充设备。但应用程序实例的信息丢失并不是关键问题,例如,如果应用程序被删除或设备被破坏(需要重新配对的烦恼,但不是关键问题)。

Firebase 匿名身份验证似乎非常适合这种情况 - 但文档暗示它只能用作临时解决方案,直到用户创建实际帐户。使用匿名身份验证作为解决方案的唯一身份验证方法有什么缺点吗?我看到的替代方案是使用基于自定义令牌的登录或电子邮件/密码身份验证的某种黑客攻击。

Ale*_*amo 6

使用匿名身份验证作为解决方案的唯一身份验证方法有什么缺点吗?

除非用户卸载该应用程序,否则不会有这种情况。

该文档暗示,在用户创建实际帐户之前,它只能用作临时解决方案。

为什么要采取临时解决方案?这是因为匿名帐户不会在应用程序卸载后持续存在。如果用户卸载该应用程序,本地保存的所有内容都将被删除,包括标识该帐户的匿名身份验证令牌。不幸的是,无法为用户回收该令牌。

我看到的替代方案是使用基于自定义令牌的登录或电子邮件/密码身份验证的某种黑客攻击。

恕我直言,最好的方法是使用匿名身份验证,但也让用户可以将其帐户与电子邮件和密码或任何其他提供商(如 Google、Facebook、Instagram 等)链接起来。

  • 为了解决临时解决方案问题,匿名身份验证在浏览器中使用时特别不稳定 - 用户需要做的就是使用不同的浏览器或浏览器配置文件,或者清除其缓存(可以通过某些策略自动执行)以使其失效他们之前的令牌。就应用程序而言,正如 Alex 所介绍的,安装和重新安装实际上与交换浏览器相同。 (2认同)