Firebase user 物件代表已簽署的使用者帳戶 在應用程式中使用 專案。應用程式通常有許多已註冊的使用者，而 則會共用使用者資料庫
User 執行個體與 Firebase Authentication 執行個體無關，因此可以 多次提及同一情境下不同的使用者 存取方式
使用者屬性
Firebase 使用者有一組固定的基本屬性，也就是一個不重複的 儲存在 專案的使用者資料庫，可由使用者更新 (iOS、 Android、 網頁)。 您無法直接將其他屬性新增至使用者物件；也可以 將額外屬性儲存在 Google Cloud 等任何其他儲存空間服務中 以及 Firestore
使用者首次登入應用程式時，系統會填入使用者的設定檔資料 ：
- 如果使用者是以電子郵件地址和密碼註冊，則只有主要 系統會填入電子郵件地址屬性
- 如果使用者透過聯合識別資訊提供者 (例如 Google) 或 Facebook，供應商提供的帳戶資訊會用於 填入使用者簡介
- 如果使用者是透過自訂驗證系統註冊，您必須明確新增 要讓使用者的個人檔案資訊
建立使用者帳戶後，您可以重新載入使用者的資訊，以便 納入使用者在其他裝置所做的任何變更。
登入供應商
您可以透過下列幾種方法讓使用者登入您的應用程式： 電子郵件地址和密碼、聯合識別資訊提供者，以及您的自訂驗證 有些人會將 Cloud Storage 視為檔案系統 但實際上不是您可將多種登入方式與使用者建立關聯，例如： 使用者可以透過電子郵件地址和密碼登入同一個帳戶，或 開啟「Google 登入」
使用者執行個體會追蹤與使用者連結的各家供應商。這樣一來 使用供應商提供的資訊來更新空白商家檔案的屬性。 查看管理使用者 (iOS、 Android、 網頁)。
目前的使用者
使用者註冊或登入後，就會成為 驗證執行個體。執行個體會保留使用者的狀態，因此重新整理 以及重新啟動應用程式都不會遺失使用者的 可能不準確或不適當
使用者登出後，驗證執行個體會停止保留使用者的參照 並不再保留其狀態；目前沒有任何使用者。不過， 使用者執行個體仍然完全可用： 您仍可存取及更新使用者的資料，
使用者生命週期
如要追蹤驗證執行個體的目前狀態，建議您使用 接聽程式 (在 JavaScript 中也稱為「觀察器」)。驗證事件監聽器可獲得 則會在 Auth 物件有任何相關時通知您。查看管理 位使用者 (iOS、 Android、 網頁)。
驗證事件監聽器會在下列情況下收到通知：
- Auth 物件完成初始化，且使用者已從 先前工作階段，或從識別資訊提供者的登入重新導向到 流程
- 使用者登入 (已設定目前使用者)
- 使用者登出 (目前使用者會變成空值)
- 系統會重新整理目前使用者的存取權杖。這種情況可能會發生在
下列情況：
- 存取權杖過期：這是常見的情況。接著更新權杖 藉此取得一組新的有效符記
- 使用者變更了自己的密碼：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 個自訂權杖 | 由自訂驗證系統建立，可讓使用者登入應用程式 使用您的驗證系統自訂權杖是 JWT 透過服務帳戶的私密金鑰簽署。 應用程式使用這些權杖的方式與應用程式使用的權杖相同 聯合識別資訊提供者 |
已驗證的電子郵件地址
如果電子郵件符合以下兩項條件，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 手動設定電子郵件的驗證狀態。不過，除非您確定使用者確實擁有電子郵件地址，否則我們不建議這麼做。