本文將進一步說明如何使用外部身分，而非 Google 帳戶，搭配 Identity-Aware Proxy (IAP)。
總覽
IAP 可控管應用程式和資源的存取權。這項服務會根據使用者身分和要求情境，判斷是否應允許使用者存取。IAP 是 Chrome Enterprise 進階版 的基石，這項企業安全解決方案可讓員工在不使用 VPN 的情況下，透過不受信任的網路工作。
根據預設，IAP 會使用 Google 身分和 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 資源可以與多個租戶建立關聯。
使用者存取資源時，您可以透過多種方式決定要使用的租戶。舉例來說，您可以提示使用者先輸入電子郵件，然後透過程式找出與電子郵件網域相符的租戶。或者，您也可以顯示列出所有有效租戶的使用者介面，並要求使用者選擇其中一個。
使用者可以屬於多個租戶，並擁有不同的存取權層級。雖然您無法使用 IAM 管理外部身分的存取控管，但 IAP 產生的 JSON Web Token 會攜帶 Identity Platform ID 權杖的宣告，應用程式可以根據這些宣告篩選存取權。
多租戶情境的例子之一，是員工福利公司有多個客戶共用單一入口網站。使用者造訪入口網站時，會先選取公司 (租戶)，然後使用雇主採用的供應商和公司憑證進行驗證。