Catch up on highlights from Firebase at Google I/O 2023. Learn more

Firebase 項目中的用戶

Firebase用戶對象表示已在您的項目中註冊應用程序的用戶帳戶。應用程序通常有很多註冊用戶，項目中的每個應用程序共享一個用戶數據庫。

用戶實例獨立於 Firebase 身份驗證實例，因此您可以在同一上下文中對不同用戶進行多個引用，並且仍然可以調用他們的任何方法。

用戶屬性

Firebase 用戶有一組固定的基本屬性——唯一 ID、主要電子郵件地址、姓名和照片 URL——存儲在項目的用戶數據庫中，用戶可以更新這些屬性（ iOS 、 Android 、網絡）。您不能直接向用戶對象添加其他屬性；相反，您可以將附加屬性存儲在任何其他存儲服務中，例如 Google Cloud Firestore。

用戶首次註冊您的應用程序時，會使用可用信息填充用戶的個人資料數據：

  • 如果用戶使用電子郵件地址和密碼註冊，則僅填充主要電子郵件地址屬性
  • 如果用戶註冊了聯合身份提供商，例如 Google 或 Facebook，提供商提供的帳戶信息將用於填充用戶的個人資料
  • 如果用戶註冊了您的自定義身份驗證系統，您必須明確地將您想要的信息添加到用戶的個人資料中

創建用戶帳戶後，您可以重新加載用戶信息以合併用戶可能在另一台設備上所做的任何更改。

登錄提供商

您可以使用多種方法讓用戶登錄您的應用程序：電子郵件地址和密碼、聯合身份提供者和您的自定義身份驗證系統。您可以將多種登錄方法與一個用戶相關聯：例如，一個用戶可以使用電子郵件地址和密碼或使用 Google 登錄登錄同一個帳戶。

用戶實例跟踪鏈接到用戶的每個提供者。這允許您使用提供商提供的信息更新空配置文件的屬性。請參閱管理用戶（ iOS 、 Android 、網絡）。

當前用戶

當用戶註冊或登錄時，該用戶成為 Auth 實例的當前用戶。該實例保留用戶的狀態，因此刷新頁面（在瀏覽器中）或重新啟動應用程序不會丟失用戶的信息。

當用戶註銷時，Auth 實例停止保持對用戶對象的引用並且不再保留其狀態；沒有當前用戶。然而，用戶實例仍然是完整的功能：如果你保留對它的引用，你仍然可以訪問和更新用戶的數據。

用戶生命週期

跟踪 Auth 實例當前狀態的推薦方法是使用偵聽器（在 JavaScript 中也稱為“觀察器”）。每當 Auth 對象發生相關事件時，Auth 偵聽器都會收到通知。請參閱管理用戶（ iOS 、 Android 、網絡）。

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 手動將電子郵件設置為已驗證，但我們建議僅在您知道用戶確實擁有該電子郵件時才這樣做。