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

Firebase 项目中的用户

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

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

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

用户属性

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

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

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

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

登录提供商

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

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

当前用户

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

当用户退出时,Auth 实例停止保持对用户对象的引用并且不再保持其状态;当前没有用户。但是,用户实例继续完全正常工作:如果您保留对它的引用,您仍然可以访问和更新用户的数据。

用户生命周期

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

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 项目中的用户。这些令牌包含用户的基本个人资料信息,包括用户的 ID 字符串,这是 Firebase 项目独有的。因为可以验证 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)。这会引发需要帐户链接的错误。
  • 用户使用受信任的提供商登录,然后使用同一电子邮件与不受信任的提供商登录(例如,Google 后跟 Facebook)。这会引发需要帐户链接的错误。
  • 用户使用不受信任的提供商登录,然后使用相同的电子邮件通过受信任的提供商登录(例如,Facebook 后跟 Google)。受信任的提供者覆盖不受信任的提供者。如果用户尝试再次使用 Facebook 登录,则会导致需要帐户链接的错误。
  • 用户使用受信任的提供商登录,然后使用相同的电子邮件从不同的受信任提供商登录(例如,Apple 后跟 Google)。两个提供者将无错误地链接。

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