使用Firebase推送通知令牌进行身份验证 - 好还是坏？

Question

我正在实习的公司目前正在使用Firebase推送通知令牌进行从移动应用到后端的身份验证，我不确定这是不是一个好习惯。它的工作方式如下：

• FirebaseInstanceID服务为每个设备发出一个唯一令牌 设备启动后

• 移动用户向服务器发送登录信息;如果服务器验证，则 移动应用程序然后将Firebase令牌上传到数据库，它就是 与用户一起存储，使令牌与用户匹配

• 在任何后续登录中，用户将从FirebaseInstanceID服务检索到的Firebase令牌发送到服务器;服务器尝试将令牌与用户匹配

  • 点击退出时，手机会向服务器发送一个空令牌（即空字符串）及其相关用户名

我觉得这是一种非常糟糕的身份验证方式，但我不知道为什么。根据我的研究，传统的方法是服务器向客户端发送临时会话ID，客户端安全地存储它，并将其发送到服务器以用于任何后续请求。有人可以解释这个Firebase业务发生了什么以及为什么它的好坏？

Answer 1

据我所知，贵公司在使用后端API对设备进行身份验证时面临着麻烦。 实际上，对于移动应用程序，这是一个棘手的问题。如果用户不必亲自进行身份验证，那么您仍然不想向任何人开放您的服务。因此，您希望有一个自动身份验证系统，该系统在您的移动应用程序的后台运行并标识设备或应用程序实例。

要做到这一点，您需要做两件事：1-以独特的方式标识设备（或应用程序实例）。 2-确保用于标识设备/应用程序实例的字符串来自真实的设备/应用程序实例。

Firebase实例ID可能是目前最好的免费方法。该移动应用要求Google服务生成唯一令牌。然后，移动应用将令牌发送到您的后端API进行身份验证。 然后，后端API通过向google服务发出请求，在身份验证过程中确保发送的令牌来自真实的应用实例。 Google服务可确保令牌是在真实设备（android / ios）上生成的，并且引用了您应用的一个实例（而不是被篡改的实例）。

这是将上面提到的安全问题委托给google服务的一种好方法（如果您不是安全专家，谁可能比您更好）。

当然，您还应该采取其他安全措施来确保后端API的完整性。例如HTTPS。

因此，我想在移动开发方面，我们应该希望有一个更好的解决方案，但是由于没有更好的解决方案，因此使用Firebase实例ID并不是一个坏习惯。

希望这会有所帮助