所有 Google 服務 (包括 Google Marketing Platform 和 Google Ads) 都會使用 Google 登入驗證使用者身分。 Google Cloud本文說明 Google 登入服務用於驗證和身分管理的網域模型。網域模型可協助您瞭解 Google 登入在企業環境中的運作方式、身分管理方式，以及如何整合外部身分識別提供者 (IdP)。下圖顯示這些實體的互動方式。
如圖所示，這個模型的中心是 Google 身分，Google 登入功能會使用這項身分。Google 身分與許多其他實體相關，這些實體在管理身分時都非常重要：
- Google 消費者版包含與 Google 服務 (例如 Gmail) 消費者用途相關的實體。
- Google for organizations 包含由 Cloud Identity 或 Google Workspace 管理的實體。這些實體最適合用來管理企業身分。
- Google Cloud 包含Google Cloud專屬的實體。
- 外部：如果將 Google 與外部 IdP 整合，這個類別會包含相關實體。
圖表中的實心箭頭表示實體彼此參照或包含彼此。虛線箭頭則表示聯盟關係。
Google 身分
身分、使用者和使用者帳戶在身分管理中扮演重要角色。這三個詞彙密切相關，有時甚至會互通使用。不過，在身分管理方面，區分這些概念很有價值：
身分是可明確識別與 Google 服務互動者的名稱。Google 會使用電子郵件地址達成這個目的。電子郵件地址是個人的 Google 身分。
驗證人員與身分關聯的程序稱為驗證或登入，可讓人員證明這確實是他們的身分。
一個人可能有多個電子郵件地址。由於 Google 服務會將電子郵件地址視為身分，因此這類使用者會被視為有多個身分。
使用者帳戶是一種資料結構，可追蹤特定身分與 Google 服務互動時應套用的屬性、活動和設定。使用者帳戶不會即時建立，必須在首次登入前完成佈建。
使用者帳戶的識別碼不會對外公開。因此，使用者介面或 API 需要您透過相關聯的身分 (例如
alice@gmail.com) 間接參照使用者帳戶。儘管有這種間接性，任何資料和設定詳細資料都與使用者帳戶相關聯，而非身分。
在多數情況下，使用者帳戶和身分之間是一對一關係，因此很容易混淆。不過，實際情況並非總是如此，如以下極端案例所示：
使用者帳戶和身分之間的關係並非固定。 您可以變更使用者帳戶的主要電子郵件地址，將不同身分與使用者建立關聯。
Cloud Identity 或 Google Workspace 管理員甚至可以互換兩位使用者的主要電子郵件地址。舉例來說，如果您互換 Alice (
alice@example.com) 和 Bob (bob@example.com) 的主要電子郵件地址，Alice 就會使用 Bob 先前的使用者帳戶，而 Bob 則會使用 Alice 先前的使用者帳戶。由於資料和設定與使用者帳戶 (而非身分) 相關聯，Alice 現在也會使用 Bob 現有的設定和資料 (而 Bob 現在會使用 Alice 的設定和資料)。下圖顯示這項關係。
在非同盟設定中，您也必須重設密碼，Alice 和 Bob 才能交換使用者帳戶。在同盟設定中，如果 Alice 和 Bob 使用外部 IdP 進行驗證，就不需要重設密碼。
身分與使用者之間的關係可能不是 1:1。消費者帳戶可刻意與多個身分建立關聯，如下圖所示。
此外，一個身分也可能對應到兩個不同的使用者帳戶。我們建議您避免這種情況，但如果發生使用者帳戶衝突，就可能出現這種情況。在這種情況下，使用者會在驗證期間看到候選畫面，並選取要使用的使用者帳戶。
Google 會區分兩種使用者帳戶：消費者使用者帳戶和受管理的使用者帳戶。以下各節將詳細說明這兩種使用者帳戶類型及其相關實體。
Google 個人帳戶
如果您擁有 Gmail 電子郵件地址 (例如 alice@gmail.com)，則您的 Gmail 帳戶是個人帳戶。同樣地，如果您使用 Google 登入頁面上的「建立帳戶」連結，並在註冊時提供您擁有的自訂電子郵件地址 (例如 alice@example.com)，則建立的帳戶也是個人帳戶。
個人帳戶
消費者帳戶是透過自助服務建立，主要用於私人用途。個人帳戶建立者可全權控管帳戶，以及使用該帳戶建立的任何資料。該使用者在註冊時使用的電子郵件地址會成為個人帳戶的主要電子郵件地址，並做為帳戶的識別資訊。該使用者可以在個人帳戶中新增電子郵件地址。這些電子郵件地址可做為額外身分，也能用來登入帳戶。
如果個人帳戶的主要電子郵件地址對應至 Cloud Identity 或 Google Workspace 帳戶的主要或次要網域，則該個人帳戶也稱為「未受管理的使用者帳戶」。
消費者帳戶可以加入任意數量的群組。
機構適用的 Google
如果貴機構使用 Google 服務，建議使用受管理的使用者帳戶。這類帳戶稱為「受管理」，因為機構可以完全控管其生命週期和設定。
受管理的使用者帳戶是 Cloud Identity 和 Google Workspace 的功能。
Cloud Identity 或 Google Workspace 帳戶
Cloud Identity 或 Google Workspace 帳戶是使用者、群組、設定和資料的頂層容器。公司申請 Cloud Identity 或 Google Workspace 時，系統會建立 Cloud Identity 或 Google Workspace 帳戶，這相當於租戶的概念。
Cloud Identity 和 Google Workspace 共用技術平台。這兩項產品使用同一組 API 和管理工具，且都將帳戶視為使用者和群組的容器，而該容器是以網域名稱識別。就管理使用者、群組和驗證而言，這兩項產品大致上可視為同等。
帳戶包含群組和一或多個機構單位。
機構單位
機構單位 (OU) 是使用者帳戶的子容器，可將 Cloud Identity 或 Google Workspace 帳戶中定義的使用者帳戶區隔為不相交的集合，方便管理。
機構單位會以階層方式排列。每個 Cloud Identity 或 Google Workspace 帳戶都有根機構單位，您可以在根機構單位下視需要建立更多機構單位。您也可以巢狀處理 OU。
透過 Cloud Identity 和 Google Workspace，您可以依據機構單位套用特定設定，例如指派授權或兩步驟驗證。這些設定會自動套用至機構單位中的所有使用者，也會由子機構單位沿用。因此，機構單位在管理 Cloud Identity 和 Google Workspace 設定方面扮演重要角色。
使用者帳戶只能屬於一個機構單位，這與群組不同。雖然機構單位可用於將設定套用至使用者帳戶，但並不適用於管理存取權。如要管理存取權，建議您使用群組。
雖然 OU 類似於Google Cloud 資料夾，但這兩個實體的用途不同，且互不相關。
受管理的使用者帳戶
受管理的使用者帳戶與消費者使用者帳戶類似，但可完全由 Cloud Identity 或 Google Workspace 帳戶的管理員控管。
受管理使用者帳戶的身分是由主要電子郵件地址定義。
主要電子郵件地址必須使用與 Cloud Identity 或 Google Workspace 帳戶中新增的主網域、次要網域或別名網域相符的網域。受管理的使用者帳戶可以有其他別名電子郵件地址和備援電子郵件地址，但這些地址不視為身分，無法用於登入。舉例來說，如果 Alice 使用 alice@example.com 做為主要電子郵件地址，並將 ally@example.com 設為別名電子郵件地址，alice@gmail.com 設為備援電子郵件地址，則 Alice 只能使用 alice@example.com 登入帳戶。
代管使用者帳戶屬於機構單位，且可成為任意數量的群組成員。
受管理的使用者帳戶適用於真人使用者，而非機器使用者。機器使用者帳戶是一種特殊帳戶，由應用程式或虛擬機器 (VM) 執行個體使用，而非由人員使用。對於機器使用者，Google Cloud 提供服務帳戶。(本文後續內容將深入探討服務帳戶)。
群組
群組可讓您將多位使用者綁在一起。您可以透過群組管理郵寄清單，或對多位使用者套用常見的存取權控管或設定。
Cloud Identity 和 Google Workspace 會依據電子郵件地址識別群組，例如 billing-admins@example.com。與使用者的主要電子郵件地址類似，群組電子郵件地址必須使用 Cloud Identity 或 Google Workspace 帳戶的主要、次要或別名網域。除非群組做為郵寄清單使用，否則電子郵件地址不需要對應至信箱。驗證程序仍會使用使用者的電子郵件地址，而非群組電子郵件地址，因此使用者無法透過群組電子郵件地址登入。
群組成員可以是下列實體：
- 使用者 (受管理的使用者或消費者帳戶)
- 其他群組
- 服務帳戶
與機構單位不同，群組不會做為容器：
- 使用者或群組可以加入任意數量的群組，不限於一個。
- 刪除群組不會刪除任何成員使用者或群組。
群組可包含任何 Cloud Identity 或 Google Workspace 帳戶的成員，以及消費者帳戶。您可以透過「禁止外部成員」設定，將成員限制為相同 Cloud Identity 或 Google Workspace 帳戶的使用者帳戶。
外部身分
將 Cloud Identity 或 Google Workspace 帳戶與外部 IdP 建立聯盟後，員工就能使用現有身分和憑證登入 Google 服務。
最基本的聯盟做法是使用 SAML 設定單一登入，將 Cloud Identity 或 Google Workspace 中的身分連結至外部 IdP 管理的身分。如要連結 alice@example.com 等身分，並啟用 Google 單一登入功能，您必須符合兩項必要條件：
- 外部 IdP 必須能辨識
alice@example.com身分，並允許使用該身分進行單一登入。 - 您的 Cloud Identity 或 Google Workspace 帳戶必須包含以
alice@example.com做為身分識別的使用者帳戶。這個使用者帳戶必須在第一次嘗試單一登入前存在。
您不必在 Cloud Identity 或 Google Workspace 中手動建立及維護使用者帳戶，只要將 SAML 型單一登入與自動使用者佈建功能結合，即可自動執行這項程序。自動佈建使用者的概念，是將外部授權來源中的所有或部分使用者和群組，同步處理至 Cloud Identity 或 Google Workspace。
視您選擇的 IdP 而定，SAML 式單一登入和自動佈建使用者可能由同一軟體元件處理，也可能需要個別元件。因此，網域模型會區分 SAML 身分識別提供者和外部授權來源。
外部 SAML 識別資訊提供者
外部 IdP 是唯一的驗證系統，可為員工提供跨應用程式的單一登入體驗。這類服務並非 Google 服務，因此稱為「外部識別資訊提供者」。
設定單一登入後，Cloud Identity 或 Google Workspace 會將驗證決策轉送至 SAML IdP。以 SAML 術語來說，Cloud Identity 或 Google Workspace 會做為服務供應商， 信任 SAML IdP 代表其驗證使用者身分。
常用的外部 IdP 包括 Active Directory Federation Services (AD FS)、Entra ID、Okta 或 Ping Identity。
外部具公信力的來源
身分識別的可靠來源是您用來建立、管理及刪除員工身分識別的唯一系統。這類資訊並非來自 Google，因此稱為「外部權威來源」。
使用者帳戶和群組可從外部授權來源自動佈建至 Cloud Identity 或 Google Workspace。佈建作業可能由授權來源本身處理，也可能透過佈建中介軟體處理。
如要有效自動佈建使用者帳戶，必須使用 SAML IdP 可辨識的身分佈建使用者帳戶。如果您在身分之間進行對應 (例如，將 Cloud Identity 或 Google Workspace 中的身分 alice@example.com 對應至 SAML IdP 中的 u12345@corp.example.com)，則 SAML IdP 和佈建中介軟體都必須執行相同的對應作業。
外部使用者帳戶
外部身分識別提供者應具備使用者帳戶的概念，可追蹤名稱、屬性和設定。
權威來源 (或佈建中介軟體) 應將所有 (或部分) 外部使用者帳戶佈建至 Cloud Identity 或 Google Workspace，以利登入。在許多情況下，只要將使用者屬性 (例如電子郵件地址、名字和姓氏) 的子集傳播至 Cloud Identity 或 Google Workspace 即可，這樣就能減少資料冗餘。
外部群組
如果外部 IdP 支援群組概念，您可以選擇將這些群組對應至 Cloud Identity 或 Google Workspace 中的群組。
對應及自動佈建群組是選用步驟，並非單一登入的必要條件，但如果您想重複使用現有群組來控管 Google Workspace 或 Google Cloud的存取權，這兩個步驟就很有用。
Google Cloud
與其他 Google 服務一樣， Google Cloud 會透過 Google 登入驗證使用者身分。 Google Cloud 此外， Google Cloud 也與 Google Workspace 和 Cloud Identity 緊密整合，方便您有效管理資源。
Google Cloud 介紹機構節點、資料夾和專案的概念。這些實體主要用於管理存取權和設定，因此在身分管理方面僅有間接關聯。不過， Google Cloud 也包含另一種使用者帳戶：服務帳戶。服務帳戶屬於專案，在身分管理中扮演重要角色。
機構節點
機構是Google Cloud 資源階層的根節點，也是專案和資料夾的容器。機構可讓您以階層結構整理資源，是集中且有效管理資源的關鍵。
每個機構都屬於單一 Cloud Identity 或 Google Workspace 帳戶。機構名稱是從對應的 Cloud Identity 或 Google Workspace 帳戶主網域名稱衍生而來。
資料夾
資料夾是 Google Cloud 資源階層中的節點，可包含專案、其他資料夾，或是兩者兼具。您可以使用資料夾，將共用常見身分與存取權管理 (IAM) 政策或機構政策的資源分組。這些政策會自動套用至資料夾中的所有專案，子資料夾也會沿用這些政策。
資料夾與機構單位類似，但兩者無關。 機構單位可協助您管理使用者，並對使用者套用常見的設定或政策；資料夾則可協助您管理專案，並對專案套用常見的設定或政策。 Google Cloud
專案
專案是資源的容器。專案在管理 API、帳單和資源存取權方面扮演重要角色。
在身分管理方面，專案是服務帳戶的容器，因此與身分管理相關。
服務帳戶
服務帳戶 (或 Google Cloud 服務帳戶) 是一種特殊的使用者帳戶，專供應用程式和其他類型的機器使用者使用。
每個服務帳戶都屬於一個 Google Cloud 專案。與代管使用者帳戶相同，管理員可以完全控管服務帳戶的生命週期和設定。
服務帳戶也會使用電子郵件地址做為身分，但與受管理的使用者帳戶不同，服務帳戶的電子郵件地址一律使用 Google 擁有的網域，例如 developer.gserviceaccount.com。
服務帳戶不會參與同盟，也沒有密碼。在 Google Cloud上，您可以使用 IAM 控制服務帳戶對運算資源 (例如虛擬機器 (VM) 或 Cloud Run 函式) 擁有的權限，不必再管理憑證。在 Google Cloud以外的環境中，您可以使用服務帳戶金鑰，讓應用程式透過服務帳戶進行驗證。
Kubernetes 服務帳戶
Kubernetes 服務帳戶是 Kubernetes 的概念，使用 Google Kubernetes Engine (GKE) 時會用到。與 Google Cloud 服務帳戶類似，Kubernetes 服務帳戶供應用程式使用，而非真人。
應用程式呼叫 Kubernetes 叢集的 Kubernetes API 時，可以使用 Kubernetes 服務帳戶進行驗證，但無法在叢集外部使用。任何 Google API 都無法辨識這些金鑰，因此無法取代 Google Cloud 服務帳戶。
將應用程式部署為 Kubernetes Pod 時，您可以將 Pod 與服務帳戶建立關聯。這項關聯可讓應用程式使用 Kubernetes API，不必設定或維護憑證或其他憑證。
使用 Workload Identity，即可將 Kubernetes 服務帳戶連結至 Google Cloud 服務帳戶。應用程式也能透過這個連結向 Google API 進行驗證，同樣不必維護憑證或其他憑證。
後續步驟
- 請參閱身分管理參考架構。