Firebase 項目中的用戶

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

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

用戶屬性

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

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

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

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

登錄提供商

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

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

當前用戶

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

當用戶退出時，Auth 實例停止保持對用戶對象的引用並且不再保持其狀態；當前沒有用戶。但是，用戶實例繼續完全正常工作：如果您保留對它的引用，您仍然可以訪問和更新用戶的數據。

用戶生命週期

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

Auth 偵聽器在以下情況下會收到通知：

  • Auth 對象完成初始化並且用戶已經從之前的會話中登錄，或者已經從身份提供者的登錄流程中被重定向
  • 用戶登錄（當前用戶已設置）
  • 用戶退出（當前用戶變為空）
  • 當前用戶的訪問令牌被刷新。這種情況可能發生在以下情況：
    • 訪問令牌過期：這是一種常見情況。刷新令牌用於獲取一組新的有效令牌。
    • 用戶更改密碼：Firebase 發出新的訪問和刷新令牌，並使舊令牌過期。出於安全原因，這會自動使用戶的令牌過期和/或在每台設備上註銷用戶。
    • 用戶重新認證：一些操作要求用戶的憑證是最近發布的；此類操作包括刪除帳戶、設置主電子郵件地址和更改密碼。不要註銷用戶然後再次登錄用戶，而是從用戶那裡獲取新憑據，並將新憑據傳遞給用戶對象的 reauthenticate 方法。

身份驗證令牌

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