在火力地堡用戶對象表示已簽署了在項目中應用程序的用戶帳戶。應用程序通常有很多註冊用戶，項目中的每個應用程序共享一個用戶數據庫。
用戶實例獨立於 Firebase 身份驗證實例，因此您可以在同一上下文中對不同用戶進行多次引用，並且仍然調用他們的任何方法。
用戶屬性
火力地堡用戶有一組固定的基本屬性，一個唯一的ID，一個主電子郵件地址，姓名和照片的URL存儲在該項目的用戶數據庫，可以由用戶（被更新的iOS ，安卓，網絡）。您不能直接向用戶對象添加其他屬性；相反，您可以將其他屬性存儲在任何其他存儲服務中，例如 Google Cloud Firestore。
用戶首次註冊您的應用時，將使用可用信息填充用戶的個人資料數據：
- 如果用戶使用電子郵件地址和密碼進行註冊，則只會填充主電子郵件地址屬性
- 如果用戶與聯合身份提供商（例如 Google 或 Facebook）註冊，則提供商提供的帳戶信息將用於填充用戶的個人資料
- 如果用戶使用您的自定義身份驗證系統註冊，您必須明確地將您想要的信息添加到用戶的個人資料中
創建用戶帳戶後，您可以重新加載用戶信息以合併用戶可能在另一台設備上所做的任何更改。
登錄提供商
您可以使用多種方法將用戶登錄到您的應用程序：電子郵件地址和密碼、聯合身份提供商和您的自定義身份驗證系統。您可以將多個登錄方法與用戶關聯：例如，用戶可以使用電子郵件地址和密碼登錄同一帳戶，或使用 Google 登錄。
用戶實例跟踪鏈接到用戶的每個提供者。這允許您使用提供者提供的信息更新空配置文件的屬性。請參閱管理用戶（的iOS ，安卓，網絡）。
當前用戶
當用戶註冊或登錄時，該用戶將成為 Auth 實例的當前用戶。該實例保留用戶的狀態，因此刷新頁面（在瀏覽器中）或重新啟動應用程序不會丟失用戶的信息。
當用戶退出時，Auth 實例停止保留對用戶對象的引用，不再保持其狀態；沒有當前用戶。但是，用戶實例仍然是完全可用的：如果您保留對它的引用，您仍然可以訪問和更新用戶的數據。
用戶生命週期
跟踪 Auth 實例當前狀態的推薦方法是使用偵聽器（在 JavaScript 中也稱為“觀察者”）。 Auth 偵聽器會在 Auth 對象發生相關事件時收到通知。請參閱管理用戶（的iOS ，安卓，網絡）。
在以下情況下，Auth 偵聽器會收到通知：
- Auth 對象完成初始化，並且用戶已經從上一個會話登錄，或者已從身份提供商的登錄流程重定向
- 一個用戶登錄（設置當前用戶）
- 用戶退出（當前用戶變為空）
- 當前用戶的訪問令牌被刷新。這種情況可能發生在以下情況：
- 訪問令牌過期：這是一種常見情況。刷新令牌用於獲取一組新的有效令牌。
- 用戶更改其密碼：Firebase 發出新的訪問和刷新令牌並使舊令牌過期。出於安全原因，這會自動使用戶的令牌過期和/或在每台設備上註銷用戶。
- 用戶重新認證：某些操作要求用戶的憑據是最近頒發的；此類操作包括刪除帳戶、設置主電子郵件地址和更改密碼。不是註銷用戶然後再次登錄用戶，而是從用戶那裡獲取新憑據，並將新憑據傳遞給用戶對象的 reauthenticate 方法。
身份驗證令牌
當您使用 Firebase 執行身份驗證時，您可能會遇到三種身份驗證令牌：
| Firebase ID 令牌 | 當用戶登錄應用時由 Firebase 創建。這些令牌是簽名的 JWT，可以安全地識別 Firebase 項目中的用戶。這些令牌包含用戶的基本個人資料信息，包括用戶的 ID 字符串，這是 Firebase 項目獨有的。由於ID令牌的完整性進行驗證，你可以將它們發送到後端服務器，以確定簽約用戶的當前。 |
| 身份提供者令牌 | 由聯合身份提供商創建，例如 Google 和 Facebook。這些令牌可以有不同的格式，但通常是 OAuth 2.0 訪問令牌。應用程序使用這些令牌來驗證用戶是否已成功通過身份提供商的身份驗證，然後將它們轉換為 Firebase 服務可用的憑據。 |
| Firebase 自定義令牌 | 由您的自定義身份驗證系統創建，以允許用戶使用您的身份驗證系統登錄應用程序。自定義令牌是JWTs使用服務帳戶的私鑰簽名。應用程序使用這些令牌就像它們使用從聯合身份提供者返回的令牌一樣。 |
經過驗證的電子郵件地址
如果一封電子郵件滿足兩個條件，則 Firebase 認為它已通過驗證：1. 用戶完成 Firebase 驗證流程 2. 該電子郵件由受信任的身份提供商（簡稱 IdP）進行驗證。
驗證電子郵件一次但隨後允許用戶更改電子郵件地址而無需重新驗證的 IdP 是不可信的。擁有域或始終需要驗證的 IdP 被視為受信任。
值得信賴的供應商：
- 谷歌（@gmail.com 地址）
- 雅虎（用於@yahoo.com 地址）
- 微軟（@outlook.com 和@hotmail.com 地址）
- Apple（始終經過驗證，因為帳戶始終經過驗證和多因素驗證）
不受信任的供應商：
- 推特
- GitHub
- Google、Yahoo 和 Microsoft 對於並非由該身份提供者頒發的域
- 電子郵件/密碼無需電子郵件驗證
在某些情況下，當用戶使用相同的電子郵件地址通過不同的提供商登錄時，Firebase 會自動關聯帳戶。然而，這只有在滿足特定標準時才會發生。要了解原因，請考慮以下情況：用戶使用 Google 使用 @gmail.com 帳戶登錄，惡意行為者使用相同的 @gmail.com 地址創建帳戶，但通過 Facebook 登錄。如果這兩個帳戶自動關聯，惡意行為者將獲得對用戶帳戶的訪問權限。
以下案例描述了我們何時自動關聯帳戶以及何時拋出需要用戶或開發者操作的錯誤：
- 用戶使用不受信任的提供商登錄，然後使用同一電子郵件（例如，Facebook 後跟 GitHub）登錄另一個不受信任的提供商。這會引發需要帳戶關聯的錯誤。
- 用戶通過受信任的提供商登錄，然後使用同一電子郵件（例如，谷歌，然後是 Facebook）從不受信任的提供商登錄。這會引發需要帳戶關聯的錯誤。
- 用戶通過不受信任的提供商登錄，然後使用相同的電子郵件（例如，Facebook 之後是 Google）從受信任的提供商登錄。受信任的提供者覆蓋不受信任的提供者。如果用戶嘗試再次使用 Facebook 登錄，則會導致需要帳戶關聯的錯誤。
- 用戶通過受信任的提供商登錄，然後使用相同的電子郵件從其他受信任的提供商登錄（例如，Apple 之後是 Google）。兩個提供程序將無錯誤地鏈接。
您可以使用 Admin SDK 手動將電子郵件設置為已驗證，但我們建議僅在您知道用戶確實擁有該電子郵件時才這樣做。