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