Firebase 項目中的用戶

Firebase用戶物件代表已註冊項目中的應用程式的用戶帳戶。應用程式通常有很多註冊用戶，專案中的每個應用程式共享一個用戶資料庫。

使用者實例獨立於 Firebase 驗證實例，因此您可以在同一上下文中對不同使用者進行多個引用，但仍可以呼叫其任何方法。

使用者屬性

Firebase 使用者擁有一組固定的基本屬性 - 唯一 ID、主電子郵件地址、姓名和照片 URL - 儲存在專案的使用者資料庫中，可由使用者（ iOS 、 Android 、 web ）進行更新。您不能直接向使用者物件新增其他屬性；相反，您可以將其他屬性儲存在任何其他儲存服務中，例如 Google Cloud Firestore。

當使用者第一次註冊您的應用程式時，將使用可用資訊填入使用者的個人資料資料：

  • 如果使用者使用電子郵件地址和密碼註冊，則僅填入主電子郵件地址屬性
  • 如果使用者註冊了聯合身分提供者（例如 Google 或 Facebook），則提供者提供的帳戶資訊將用於填充使用者的個人資料
  • 如果使用者使用您的自訂身分驗證系統註冊，您必須將所需的資訊明確新增至使用者的個人資料中

建立使用者帳戶後，您可以重新載入使用者資訊以納入使用者可能在其他裝置上所做的任何變更。

登入提供者

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

使用者實例追蹤與使用者連結的每個提供者。這允許您使用提供者提供的資訊更新空設定檔的屬性。請參閱管理用戶（ iOS 、 Android 、 Web ）。

目前用戶

當使用者註冊或登入時，該使用者將成為 Auth 實例的目前使用者。此實例保留使用者的狀態，以便刷新頁面（在瀏覽器中）或重新啟動應用程式不會遺失使用者的資訊。

當使用者退出時，Auth 實例停止保留對使用者物件的引用，並且不再保留其狀態；目前沒有使用者。但是，使用者實例仍然具有完整的功能：如果您保留對它的引用，您仍然可以存取和更新使用者的資料。

用戶生命週期

追蹤 Auth 實例目前狀態的建議方法是使用偵聽器（在 JavaScript 中也稱為「觀察者」）。每當 Auth 物件發生相關事件時，Auth 偵聽器都會收到通知。請參閱管理用戶（ iOS 、 Android 、 Web ）。

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

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

用戶自助服務

預設情況下，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 專案中的使用者。這些令牌包含使用者的基本個人資料訊息，包括使用者的 ID 字串，該字串對於 Firebase 專案是唯一的。由於可以驗證 ID 令牌的完整性，因此您可以將它們傳送到後端伺服器來識別目前登入的使用者。
身分提供者令牌由聯合身分提供者創建，例如 Google 和 Facebook。這些令牌可以具有不同的格式，但通常是 OAuth 2.0 存取權杖。應用程式使用這些令牌來驗證使用者是否已成功通過身分提供者的身份驗證，然後將其轉換為 Firebase 服務可以使用的憑證。
Firebase 自訂令牌由您的自訂身份驗證系統創建，以允許使用者使用您的身份驗證系統登入應用程式。自訂令牌是使用服務帳戶的私鑰簽署的JWT。應用程式使用這些令牌就像使用從聯合身分提供者返回的令牌一樣。

已驗證的電子郵件地址

如果電子郵件符合兩個條件，Firebase 就會認為該電子郵件已通過驗證：

  1. 使用者完成 Firebase 驗證流程
  2. 該電子郵件由受信任的身份提供者（簡稱 IdP）進行驗證。

驗證電子郵件一次但隨後允許使用者更改電子郵件地址而不需要重新驗證的 IdP 不受信任。擁有網域或始終需要驗證的 IdP 被視為可信。

值得信賴的供應商：

  • Google（適用於@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 手動將電子郵件設定為已驗證，但我們建議僅在您知道使用者確實擁有該電子郵件時才執行此操作。