获取我们在 Firebase 峰会上发布的所有信息,了解 Firebase 可如何帮助您加快应用开发速度并满怀信心地运行应用。了解详情

Firebase 项目中的用户

使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。

Firebase用户对象表示已在您的项目中注册应用程序的用户帐户。应用程序通常有很多注册用户,项目中的每个应用程序共享一个用户数据库。

用户实例独立于 Firebase 身份验证实例,因此您可以在同一上下文中对不同用户进行多个引用,并且仍然可以调用他们的任何方法。

用户属性

Firebase 用户有一组固定的基本属性——唯一 ID、主要电子邮件地址、姓名和照片 URL——存储在项目的用户数据库中,用户可以更新这些属性( iOSAndroid网络)。您不能直接向用户对象添加其他属性;相反,您可以将附加属性存储在任何其他存储服务中,例如 Google Cloud Firestore。

用户首次注册您的应用程序时,会使用可用信息填充用户的个人资料数据:

  • 如果用户使用电子邮件地址和密码注册,则仅填充主要电子邮件地址属性
  • 如果用户注册了联合身份提供商,例如 Google 或 Facebook,提供商提供的帐户信息将用于填充用户的个人资料
  • 如果用户注册了您的自定义身份验证系统,您必须明确地将您想要的信息添加到用户的个人资料中

创建用户帐户后,您可以重新加载用户信息以合并用户可能在另一台设备上所做的任何更改。

登录提供商

您可以使用多种方法让用户登录您的应用程序:电子邮件地址和密码、联合身份提供者和您的自定义身份验证系统。您可以将多种登录方法与一个用户相关联:例如,一个用户可以使用电子邮件地址和密码或使用 Google 登录登录同一个帐户。

用户实例跟踪链接到用户的每个提供者。这允许您使用提供商提供的信息更新空配置文件的属性。请参阅管理用户( iOSAndroid网络)。

当前用户

当用户注册或登录时,该用户成为 Auth 实例的当前用户。该实例保留用户的状态,因此刷新页面(在浏览器中)或重新启动应用程序不会丢失用户的信息。

当用户注销时,Auth 实例停止保持对用户对象的引用并且不再保留其状态;没有当前用户。然而,用户实例仍然是完整的功能:如果你保留对它的引用,你仍然可以访问和更新用户的数据。

用户生命周期

跟踪 Auth 实例当前状态的推荐方法是使用侦听器(在 JavaScript 中也称为“观察器”)。每当 Auth 对象发生相关事件时,Auth 侦听器都会收到通知。请参阅管理用户( iOSAndroid网络)。

Auth 侦听器在以下情况下会收到通知:

  • Auth 对象完成初始化并且用户已从上一个会话登录,或已从身份提供者的登录流程重定向
  • 用户登录(设置当前用户)
  • 用户注销(当前用户变为空)
  • 当前用户的访问令牌被刷新。这种情况可能发生在以下情况:
    • 访问令牌过期:这是一种常见情况。刷新令牌用于获取一组新的有效令牌。
    • 用户更改密码:Firebase 发出新的访问和刷新令牌,并使旧令牌过期。出于安全原因,这会自动使用户的令牌过期和/或在每台设备上注销用户。
    • 用户重新认证:一些操作需要用户的凭证是最近颁发的;此类操作包括删除帐户、设置主电子邮件地址和更改密码。不是注销用户然后再次登录用户,而是从用户那里获取新凭据,并将新凭据传递给用户对象的 reauthenticate 方法。

用户自助服务

默认情况下,Firebase 允许用户在没有管理干预的情况下注册和删除他们的帐户。在许多情况下,这使最终用户能够以最小的摩擦发现您的应用程序或服务并加入(或脱离)。

但是,在某些情况下,您希望管理员使用 Admin SDK 或 Firebase 控制台手动或以编程方式创建用户。在这些情况下,您可以从Firebase 身份验证设置页面禁用用户操作,以防止最终用户创建和删除帐户。如果您使用多租户,则需要发出 HTTP 请求以在每个租户的基础上禁用这些功能。

如果最终用户试图在您的系统中创建或删除帐户,Firebase 服务将返回错误代码:Web API 调用auth/admin-restricted-operation或 Android 和 iOS 的ERROR_ADMIN_RESTRICTED_OPERATION 。您应该通过要求用户为您的服务采取适当的操作来优雅地处理前端的错误。

授权令牌

当您使用 Firebase 执行身份验证时,您可能会遇到三种身份验证令牌:

Firebase ID 令牌当用户登录应用程序时由 Firebase 创建。这些令牌是经过签名的 JWT,可以安全地识别 Firebase 项目中的用户。这些令牌包含用户的基本个人资料信息,包括 Firebase 项目独有的用户 ID 字符串。由于可以验证 ID 令牌的完整性,您可以将它们发送到后端服务器以识别当前登录的用户。
身份提供商令牌由联合身份提供商创建,例如 Google 和 Facebook。这些令牌可以有不同的格式,但通常是 OAuth 2.0 访问令牌。应用程序使用这些令牌来验证用户是否已成功通过身份提供者的身份验证,然后将它们转换为 Firebase 服务可用的凭据。
Firebase 自定义令牌由您的自定义身份验证系统创建,以允许用户使用您的身份验证系统登录应用程序。自定义令牌是使用服务帐户的私钥签名的 JWT。应用程序使用这些令牌就像使用从联合身份提供商返回的令牌一样。

已验证的电子邮件地址

如果满足两个条件,Firebase 会认为电子邮件已通过验证:

  1. 用户完成 Firebase 验证流程
  2. 电子邮件由受信任的身份提供者(简称 IdP)验证。

验证电子邮件一次,但随后允许用户更改电子邮件地址而无需重新验证的 IdP 不受信任。拥有域或始终需要验证的 IdP 被认为是可信的。

值得信赖的供应商:

  • 谷歌(@gmail.com 地址)
  • 雅虎(@yahoo.com 地址)
  • Microsoft(@outlook.com 和@hotmail.com 地址)
  • Apple(始终经过验证,因为帐户始终经过验证和多因素身份验证)

不受信任的提供商:

  • Facebook
  • 推特
  • GitHub
  • Google、Yahoo 和 Microsoft 用于非该身份提供商颁发的域
  • 没有电子邮件验证的电子邮件/密码

在某些情况下,当用户使用同一电子邮件地址登录不同提供商时,Firebase 会自动关联帐户。然而,这只有在满足特定标准时才会发生。要了解原因,请考虑以下情况:用户使用 @gmail.com 帐户登录 Google,恶意行为者使用相同的 @gmail.com 地址创建帐户,但通过 Facebook 登录。如果这两个帐户自动链接,恶意行为者将获得对用户帐户的访问权限。

以下情况描述了我们何时自动链接帐户以及何时抛出需要用户或开发人员操作的错误:

  • 用户登录不受信任的提供商,然后使用同一电子邮件登录另一个不受信任的提供商(例如,Facebook,然后是 GitHub)。这会引发需要帐户链接的错误。
  • 用户登录受信任的提供商,然后使用同一电子邮件登录不受信任的提供商(例如,谷歌,然后是 Facebook)。这会引发需要帐户链接的错误。
  • 用户登录不受信任的提供商,然后使用同一电子邮件登录受信任的提供商(例如,Facebook,然后是 Google)。受信任的提供者会覆盖不受信任的提供者。如果用户尝试再次使用 Facebook 登录,将导致需要帐户链接的错误。
  • 用户登录受信任的提供商,然后使用同一电子邮件登录不同的受信任提供商(例如,Apple,然后是 Google)。两个提供商都将无误地链接。

您可以使用 Admin SDK 手动将电子邮件设置为已验证,但我们建议仅在您知道用户确实拥有该电子邮件时才这样做。