Firebase Authentication「使用者」物件代表已在專案中註冊應用程式的使用者帳戶。應用程式通常會有許多註冊使用者，且專案中的每個應用程式都會共用使用者資料庫。
使用者執行個體與 Firebase Authentication 執行個體無關，因此您可以在相同環境中參照多位使用者，並呼叫任何方法。
使用者屬性
Authentication 使用者有一組固定的基本屬性 (專案使用者資料庫中儲存的專屬 ID、主要電子郵件地址、名稱和相片網址)，可由使用者更新 (iOS、Android、網頁)。您無法直接將其他屬性新增至使用者物件，但可以將其他屬性儲存在任何其他儲存空間服務中，例如 Google Cloud Firestore。
使用者首次註冊應用程式時，系統會使用可用資訊填入使用者個人資料：
- 如果使用者是透過電子郵件地址和密碼註冊，系統只會填入主要電子郵件地址屬性
- 如果使用者透過聯合身分識別資訊提供者 (例如 Google 或 Facebook) 註冊，系統會使用提供者提供的帳戶資訊填入使用者設定檔
- 如果使用者是透過自訂驗證系統註冊，您必須明確將所需資訊新增至使用者設定檔
建立使用者帳戶後，您可以重新載入使用者資訊，納入使用者在其他裝置上所做的任何變更。
登入資訊提供者
您可以透過多種方式讓使用者登入應用程式：電子郵件地址和密碼、聯合身分提供者，以及自訂驗證系統。您可以將多種登入方式與使用者建立關聯，例如使用者可以透過電子郵件地址和密碼登入同一帳戶，也可以使用 Google 登入。
使用者執行個體會追蹤連結至使用者的每個供應商。這樣一來，您就能使用供應商提供的資訊，更新空白設定檔的屬性。請參閱「管理使用者」(iOS、Android、網頁版)。
目前使用者
使用者註冊或登入時，會成為 Auth 執行個體的目前使用者。這個執行個體會保留使用者的狀態，因此重新整理網頁 (在瀏覽器中) 或重新啟動應用程式時，不會遺失使用者的資訊。
使用者登出時，Auth 執行個體會停止保留使用者物件的參照，且不再保存其狀態，因此沒有目前使用者。不過，使用者例項仍可正常運作：如果您保留參照，還是可以存取及更新使用者資料。
使用者生命週期
建議使用監聽器 (在 JavaScript 中也稱為「觀察器」) 追蹤 Auth 執行個體的目前狀態。每當 Auth 物件發生相關事件時，系統就會通知 Auth 監聽器。請參閱「管理使用者」(iOS、Android、網頁版)。
在下列情況下，系統會通知 Auth 監聽器：
- Auth 物件完成初始化，且使用者已從先前的工作階段登入，或已從身分識別提供者的登入流程重新導向
- 使用者登入 (設定目前使用者)
- 使用者登出 (目前使用者變成空值)
- 系統會重新整理目前使用者的存取權杖。在下列情況下，可能會發生這種情況：
- 存取權杖過期：這是常見情況。更新權杖可用於取得一組新的有效權杖。
- 使用者變更密碼：Authentication發出新的存取權和重新整理權杖，並使舊權杖失效。基於安全考量，系統會自動讓使用者的符記失效，並/或登出所有裝置。
- 使用者重新驗證：部分動作需要使用者最近發行的憑證，包括刪除帳戶、設定主要電子郵件地址及變更密碼。請從使用者取得新憑證，並將新憑證傳遞至使用者物件的重新驗證方法，而不是登出使用者再重新登入。
使用者自助式服務
根據預設，Firebase Authentication可讓使用者註冊及刪除帳戶，無需管理員介入。在許多情況下，這可讓使用者輕鬆探索您的應用程式或服務，並順利完成加入 (或退出) 程序。
不過，有時您會希望管理員手動或以程式輔助方式建立使用者，無論是使用 Admin SDK 或Firebase控制台。在這些情況下，您可以從「設定」Firebase Authentication頁面停用使用者動作，防止使用者建立及刪除帳戶。如果您使用多重租戶，則需要發出 HTTP 要求，逐一停用各個租戶的這些功能。
如果使用者嘗試在系統中建立或刪除帳戶，Firebase Authentication服務會傳回錯誤代碼：Web API 呼叫為 auth/admin-restricted-operation，Android 和 iOS 則為 ERROR_ADMIN_RESTRICTED_OPERATION。您應在前端妥善處理錯誤，要求使用者為您的服務採取適當行動。
驗證權杖
使用 Authentication 進行驗證時，可能會遇到三種驗證權杖：
| Authentication ID 權杖 | 由 Authentication 在使用者登入應用程式時建立。這些權杖是經過簽署的 JWT，可安全地識別 Firebase 專案中的使用者。這些權杖包含使用者的基本個人資料資訊，包括使用者 ID 字串 (Firebase 專案專屬)。由於可以驗證 ID 權杖的完整性，因此您可以將權杖傳送至後端伺服器，識別目前登入的使用者。 |
| 識別資訊提供者權杖 | 由聯合身分提供者 (例如 Google 和 Facebook) 建立。這類權杖的格式可能不同，但通常是 OAuth 2.0 存取權杖。應用程式會使用這些權杖驗證使用者是否已透過身分識別提供者成功驗證，然後將權杖轉換為 Authentication 服務可用的憑證。 |
| Authentication 個自訂權杖 | 由自訂驗證系統建立，可讓使用者透過您的驗證系統登入應用程式。自訂權杖是 使用服務帳戶私密金鑰簽署的 JWT。應用程式使用這些權杖的方式，與使用聯合身分識別提供者傳回的權杖類似。 |
已驗證的電子郵件地址
Authentication 會在電子郵件符合下列兩項條件時，將其視為已驗證：
- 使用者完成Authentication驗證流程
- 電子郵件是由受信任的識別資訊提供者 (簡稱 IdP) 驗證。
如果 IdP 只驗證一次電子郵件，但允許使用者變更電子郵件地址，且不要求重新驗證，則不值得信任。如果 IdP 擁有網域或一律要求驗證，則視為受信任。
信任的供應商：
- Google (適用於 @gmail.com 地址)
- Yahoo (適用於 @yahoo.com 地址)
- Microsoft (適用於 @outlook.com 和 @hotmail.com 地址)
- Apple (一律通過驗證，因為帳戶一律經過驗證並啟用多重驗證)
不受信任的供應商：
- GitHub
- Google、Yahoo 和 Microsoft (適用於非由該身分識別提供者核發的網域)
- 電子郵件地址 / 密碼 (未驗證電子郵件地址)
在某些情況下，如果使用者透過不同供應商登入時使用相同的電子郵件地址，Authentication 會自動連結帳戶。不過，只有在符合特定條件時，才會發生這種情況。為瞭解原因，請參考以下情況：使用者透過 Google 登入 @gmail.com 帳戶，而惡意行為人使用相同的 @gmail.com 位址建立帳戶，但透過 Facebook 登入。如果這兩個帳戶自動連結，惡意行為人就能存取使用者的帳戶。
以下說明系統何時會自動連結帳戶，以及何時會擲回錯誤，要求使用者或開發人員採取行動：
- 使用者先透過不受信任的供應商登入，然後使用相同電子郵件地址透過另一個不受信任的供應商登入 (例如先透過 Facebook 登入，再透過 GitHub 登入)。這會擲回需要連結帳戶的錯誤。
- 使用者先透過信任的供應商登入，然後透過不信任的供應商登入，但使用相同的電子郵件地址 (例如先透過 Google 登入，再透過 Facebook 登入)。這會擲回需要連結帳戶的錯誤。
- 使用者先透過不信任的供應商登入，然後透過信任的供應商登入，但使用相同的電子郵件地址 (例如先透過 Facebook 登入，然後透過 Google 登入)。系統會以信任的提供者覆寫不信任的提供者。如果使用者嘗試再次透過 Facebook 登入，系統會發生錯誤，要求連結帳戶。
- 使用者先透過信任的供應商登入，然後使用相同電子郵件地址透過其他信任的供應商登入 (例如先透過 Apple 登入，再透過 Google 登入)。兩個供應商都會連結，不會發生錯誤。
您可以使用 Admin SDK 手動將電子郵件設為已驗證，但建議您只在確定使用者確實擁有該電子郵件時才這麼做。