Firebase 用户对象表示已注册您项目中应用的用户账号。应用通常有众多注册用户，同一个项目中的各个应用共享一个用户数据库。
用户实例独立于 Firebase Authentication 实例，因此您可以在一个环境中拥有对不同用户的多项引用，还可调用这些引用的任何方法。
用户属性
Firebase 用户具有一组固定的基本属性，即唯一 ID、主电子邮件地址、用户名和照片网址。这些属性存储在项目的用户数据库中，并可由用户进行更新（iOS、Android、Web）。您无法向用户对象直接添加其他属性，但可以将更多属性存储在 Google Cloud Firestore 等其他存储服务中。
用户初次注册您的应用时，系统会使用可获取的信息来填充该用户的个人资料数据：
- 如果用户使用电子邮件地址和密码注册，系统将只填充主电子邮件地址属性
- 如果用户通过联合身份提供方（如 Google 或 Facebook）注册，系统会使用来自该提供方的账号信息填充用户个人资料
- 如果用户使用您的自定义身份验证系统注册，您必须将所需的信息明确添加至用户个人资料
在用户账号创建后，您可以重新加载该用户的信息，以合并该用户可能在另一台设备上所做的任何更改。
登录提供方
您可以使用几种方法将用户登录到您的 Firebase 应用：电子邮件地址与密码、联合身份提供方和您的自定义身份验证系统。您可以将多种登录方法与一位用户关联：例如，让用户既可以使用电子邮件地址和密码，也可以使用“Google 登录”方法登录同一个账号。
用户实例会跟踪与该用户关联的每个提供方，因此您可以使用来自提供方的信息更新空白的个人资料属性。请参阅“管理用户”（iOS、Android、Web）。
当前用户
用户在注册或登录后，即成为 Auth 实例的当前用户。该实例会保留该用户的状态，因此刷新页面（在浏览器中）或重启应用不会导致该用户的信息丢失。
当用户退出时，Auth 实例会停止保存对用户对象的引用，不再保留其状态，所以没有当前用户。但用户实例仍然完全有效：如果您保存对该实例的引用，则仍可访问和更新该用户的数据。
用户生命周期
如需跟踪 Auth 实例的当前状态，建议使用监听器（在 JavaScript 中称为“观察者”）。Auth 对象发生相关情况时，Auth 监听器都会随时收到通知。请参阅“管理用户”（iOS、Android、Web）。
Auth 监听器在以下情况会收到通知：
- Auth 对象完成初始化，并且用户已通过之前的会话登录或者是通过身份提供方的登录流程重定向而来
- 用户登录账号（已设置当前用户）
- 用户退出账号（当前用户变为 null）
- 当前用户的访问令牌已刷新。以下条件可能发生这种情况：
- 访问令牌到期：这是常见情况。可刷新令牌来获取一组有效的新令牌。
- 用户更改自己的密码：Firebase 会签发新的访问和刷新令牌，同时将旧令牌标记为已过期。这意味着，为了确保安全，该用户在每台设备上的令牌都会自动过期，并且（或者）该用户会自动退出账号。
- 用户重新进行身份验证：有些操作要求用户凭据是最近颁发的，这些操作包括删除账号、设置主电子邮件地址和更改密码。您不应让用户退出后再登录，而是应向用户索取新凭据，并将其传递至用户对象的相关方法以重新进行身份验证。
用户自助服务
默认情况下，Firebase 允许用户注册和删除自己的账号，而无需管理干预。很多情况下，这让最终用户能够发现并通过较少的操作使用（或停止使用）您的应用或服务。
但是，在某些情况下，您希望由管理员使用 Admin SDK 或 Firebase 控制台手动或以编程方式创建用户。在这些情况下，您可以在 Firebase Authentication 设置页面中停用用户操作，以防最终用户创建和删除账号。如果您使用的是多租户，则需要发出 HTTP 请求并按租户停用这些功能。
如果最终用户尝试在系统中创建或删除账号，Firebase 服务将返回错误代码：auth/admin-restricted-operation（Web API 调用）或 ERROR_ADMIN_RESTRICTED_OPERATION（Android 和 iOS）。您应该要求用户为服务执行适当的操作，从而在前端妥善处理错误。
身份验证令牌
执行 Firebase 身份验证时，您可能会遇到三种身份验证令牌：
| Firebase ID 令牌 | 当用户登录应用时由 Firebase 创建。这些令牌是已签署的 JWT，可在 Firebase 项目中安全地识别用户。这些令牌包含用户的基本个人资料信息，包括用户的 ID 字符串，此字符串在 Firebase 项目中具有唯一性。由于可以验证 ID 令牌的完整性，您可以将其发送给后端服务器，以识别当前登录的用户。 |
| 身份提供方令牌 | 由联合身份提供方（例如 Google 和 Facebook）创建。这些令牌可能有不同的格式，但常用的是 OAuth 2.0 访问令牌。应用使用这些令牌来确认用户已成功通过身份提供方的身份验证，然后将其转换成可供 Firebase 服务使用的凭据。 |
| Firebase 自定义令牌 | 由自定义身份验证系统创建，使用户能够登录到使用您自定义的身份验证系统的 Firebase 应用。自定义令牌是使用服务账号私钥签署的 JWT。Firebase 应用使用这些令牌的方式与其使用联合身份提供方返回的令牌的方式非常相似。 |
已验证的电子邮件地址
如果一个电子邮件地址符合以下两个条件，Firebase 会将其视为经过验证的电子邮件地址：
- 用户完成 Firebase 验证流程
- 此电子邮件地址由受信任的身份提供方（简称 IdP）进行验证。
如果 IdP 只需验证一次电子邮件地址，但允许用户更改电子邮件地址（无需重新验证），则它们将不受信任。拥有网域或始终要求验证的 IdP 会受信任。
受信任的提供方：
- Google（针对 @gmail.com 地址）
- Yahoo（针对 @yahoo.com 地址）
- Microsoft（针对 @outlook.com 和 @hotmail.com 地址）
- Apple（始终要验证，因为账号始终进行验证且要进行多重身份验证）
不受信任的提供方：
- GitHub
- Google、Yahoo 和 Microsoft（针对不是该身份提供方提供的网域）
- 未进行电子邮件验证的电子邮件地址/密码
在某些情况下，当用户使用相同的电子邮件地址登录不同提供方时，Firebase 会自动关联账号。但是，只有在满足特定条件时才会发生这种情况。要想理解其中缘由，请考虑以下情况：用户通过 @gmail.com 账号登录 Google，而恶意操作者使用相同的 @gmail.com 地址创建账号，但通过 Facebook 登录。如果这两个账号是自动关联的，则恶意操作者将获得相应用户账号的访问权限。
以下情况说明了我们何时自动关联账号以及何时抛出需要用户或开发者执行操作的错误：
- 用户登录不受信任的提供方，然后使用同一电子邮件地址登录另一不受信任的提供方（例如，先登录 Facebook，再登录 GitHub）。这会抛出要求账号关联的错误。
- 用户登录受信任的提供方，然后使用同一电子邮件地址登录不受信任的提供方（例如，先登录 Google，再登录 Facebook）。这会抛出要求账号关联的错误。
- 用户登录不受信任的提供方，然后使用同一电子邮件地址登录受信任的提供方（例如，先登录 Facebook，再登录 Google）。受信任的提供方会覆盖不受信任的提供方。如果用户再次尝试登录 Facebook，则会引发要求账号关联的错误。
- 用户登录受信任的提供方，然后使用同一电子邮件地址登录其他受信任的提供方（例如，先登录 Apple，再登录 Google）。两个提供方可以关联而不会发生错误。
您可以使用 Admin SDK 手动将某电子邮件地址设置为“已验证”，但是我们建议您仅在知道用户确实是该电子邮件地址的所有者的情况下再执行此操作。