所有 Google 服務 (包括 Google Cloud、Google Marketing Platform 和 Google Ads) 都會使用 Google 登入 驗證使用者。本文說明 Google 登入服務用於驗證和身分管理的網域模型。網域模型可協助您瞭解 Google 登入在企業環境中的運作方式、身分管理方式，以及如何促進與外部身分提供者 (IdP) 的整合。下圖顯示這些實體的互動方式。
如圖所示，模型的中心是 Google 身分，這是 Google 登入所使用的身分。Google 身分與多個其他實體相關，這些實體在管理身分時都會有所關聯：
- Google 消費者服務包含與 Gmail 等以消費者為主的 Google 服務相關實體。
- Google 機構包含由 Cloud Identity 或 Google Workspace 管理的實體。這些實體最適合用於管理企業身分。
- Google Cloud 包含Google Cloud專屬的實體。
- 外部：如果您將 Google 與外部 IdP 整合，這裡會包含相關實體。
圖表中的實心箭頭表示實體彼此參照或互相包含。相反地，虛線箭頭則表示聯邦關係。
Google 身分
身分、使用者和使用者帳戶在身分管理中扮演著關鍵角色。這三個詞彙之間的關係密切，有時甚至可互通使用。不過，在身分管理的情況下，有必要區分這兩個概念：
「身分」是指可明確識別與 Google 服務互動的使用者名稱。Google 會使用電子郵件地址做為這項用途。使用者的電子郵件地址視為該使用者的 Google 身分。
驗證使用者與身分之間的關聯程序稱為驗證或登入，使用者必須證明這確實是自己的身分。
使用者可能擁有多個電子郵件地址。由於 Google 服務會使用電子郵件地址做為身分識別，因此這類使用者會被視為擁有多個身分。
使用者帳戶是一種資料結構，可追蹤特定身分與 Google 服務互動時應套用的屬性、活動和設定。系統不會即時建立使用者帳戶，但需要在首次登入前先行佈建。
使用者帳戶的 ID 不會對外公開。因此，使用者介面或 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 交換使用者帳戶。在聯盟設定中，如果小愛和 Bob 使用外部 IdP 進行驗證，就不需要重設密碼。
ID 和使用者之間的關係不一定是 1:1。消費者帳戶可以有意與多個身分建立關聯，如以下圖表所示。
一個身分識別資訊也可能會對應到兩個不同的使用者帳戶。我們建議您避免這種情況，但如果使用者帳戶相衝突，就可能發生這種情況。在這種情況下，使用者在驗證期間會看到候選畫面，可在其中選取要使用的使用者帳戶。
Google 會區分兩種使用者帳戶：個人使用者帳戶和受管理使用者帳戶。以下各節將詳細說明這兩種使用者帳戶及其相關實體。
Google 消費者服務
如果您擁有 alice@gmail.com 這類 Gmail 電子郵件地址，則您的 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，您可以在其中視需要建立更多 OU。您也可以巢狀處理 OU。
Cloud Identity 和 Google Workspace 可讓您依據 OU 套用特定設定，例如授權指派或2 步驟驗證。這些設定會自動套用至機構單位中的所有使用者，並由子機構單位繼承。因此，機構單位在管理 Cloud Identity 和 Google Workspace 設定時扮演著關鍵角色。
使用者帳戶不得屬於多個 OU，這點與群組不同。雖然 OU 可用於將設定套用至使用者帳戶，但不建議用於管理存取權。如要管理存取權，建議您使用群組。
雖然 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)、Eentra ID、Okta 或 Ping Identity。
外部權威來源
您用來建立、管理及刪除員工身分的唯一系統，就是身分可靠來源。這是 Google 以外的來源，因此稱為外部權威來源。
系統可從外部權威來源自動將使用者帳戶和群組佈建至 Cloud Identity 或 Google Workspace。佈建作業可能由權威來源本身處理，也可能透過佈建中介軟體處理。
如要讓自動化使用者帳戶佈建功能生效，您必須為使用者佈建 SAML IdP 可辨識的 ID。如果您在 ID 之間建立對應 (例如將 Cloud Identity 或 Google Workspace 中的 ID 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 Cloud 與其他 Google 服務一樣， Google Cloud 會透過 Google 登入服務驗證使用者。 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 進行驗證，而且不需要維護憑證或其他憑證。
後續步驟
- 請參閱身分管理的參考架構。