本文將進一步說明如何搭配使用外部身分和 Identity-Aware Proxy (IAP)，而非 Google 帳戶。
總覽
IAP 可控管應用程式和資源的存取權。這項服務會根據使用者身分和要求背景資訊，判斷是否應允許使用者存取。IAP 是 Chrome Enterprise 進階版 的基石。Chrome Enterprise 進階版是一項企業安全解決方案，可讓員工在無需使用 VPN 的情況下，從不受信任的網路成功連線工作。
IAP 預設會使用 Google Identity 和 IAM。改用 Identity Platform，即可透過各種外部身分識別資訊提供者驗證使用者，例如：
- 電子郵件地址/密碼
- OAuth (Google、Facebook、Twitter、GitHub、Microsoft 等)
- SAML
- OIDC
- 電話號碼
- 自訂
- 匿名
如果您的應用程式已使用外部驗證系統，且將使用者遷移至 Google 帳戶不切實際，這項功能就十分實用。
多用戶群架構
Identity Platform 多用戶群架構最初是為 B2B 情境設計，也就是一家公司向其他公司銷售服務。在這種情況下，開發人員通常會希望將使用者群體劃分為獨立的集區。這些孤島稱為「租戶」。
請參考下方的虛構關係圖：
在本範例中，Acme 是汽車製造商 (代理商)，使用 Identity Platform 為經銷商 (房客) 提供服務。這些經銷商則為顧客、員工和承包商提供服務。雖然服務由製造商擁有，但每個經銷商都可以使用自己的身分驗證供應商組合進行驗證。使用者工作階段和資料會以個別租戶為範圍，因此如果使用者與多個經銷商有關係，系統會分別處理。
視用途而定，您可以透過多種方式建構房客階層。
沒有租戶
只有在需要隔離資源時，才需要多租戶。並非所有應用程式都必須符合這項規定。舉例來說，如果您只有一個 App Engine 應用程式，並想封鎖網路外部所有使用者的存取權，就不需要多重租戶。根據預設，Identity Platform 會以專案為單位儲存及驗證使用者，因此您不必進行額外設定。
另一個例子是擁有數個子公司的企業集團。即使每個子公司都有自己的受管理驗證系統 (使用 OIDC 或 SAML)，所有員工可能仍享有相同的高階福利，例如醫療保健、休假和薪資。在這種情況下，專案層級的驗證就已足夠。
每個資源只能有一個租戶
根據預設，非租戶 Identity Platform 權杖在專案層級有效。從理論上來說，這表示使用者可以透過一個 IAP 資源進行驗證，然後使用權杖存取同一專案中的其他服務。這會造成安全風險。
為防止權杖外洩，請為每個 IAP 指派專屬的租戶，藉此隔離各個 IAP。在特定租戶環境中鑄造的權杖僅適用於該租戶。如果使用者嘗試存取使用不同租戶的其他 IAP 資源，系統會要求他們重新驗證。
每個資源有多個租戶
單一 IAP 資源可以有多個相關聯的租戶。
使用者存取資源時，您有多種方式可決定要使用的租戶。舉例來說，您可以提示使用者先輸入電子郵件地址，然後以程式輔助方式找出與電子郵件網域相符的房客。或者，您也可以顯示列出所有有效租戶的 UI，並要求使用者選擇其中一個。
使用者可屬於多個租戶，並擁有不同層級的存取權。 雖然您無法使用 IAM 管理外部身分的存取控管，但 IAP 產生的 JSON 網頁權杖會攜帶 Identity Platform ID 權杖的權杖附加資訊，應用程式可以根據這些權杖附加資訊篩選存取權。
舉例來說，員工福利公司有多個客戶共用單一網路入口，就是多租戶情境。使用者造訪入口網站時，首先會選取公司 (租戶)，然後使用雇主採用的任何供應商，透過公司憑證進行驗證。