在 Microsoft Entra 識別碼上，將單一租使用者應用程式轉換為多租使用者
如果您提供軟體即服務 （SaaS） 應用程式給許多組織，您可以將應用程式設定為接受來自任何 Microsoft Entra 租使用者的登入，方法是將它轉換成多租使用者。 任何 Microsoft Entra 租使用者中的使用者都能夠在同意將帳戶與您的應用程式搭配使用之後登入您的應用程式。
對於具有自己帳戶系統的現有應用程式（或其他來自其他雲端提供者的登入），您應該透過 OAuth2、OpenID 連線 或 SAML 新增登入程式代碼，並在應用程式中放置 [使用 Microsoft 登入] 按鈕。
在本操作指南中，您將執行將單一租使用者應用程式轉換成 Microsoft Entra 多租使用者應用程式所需的四個步驟：
如果您想要嘗試使用我們的其中一個範例，請參閱建置使用 Microsoft Entra ID 和 OpenID 呼叫 Microsoft Graph 的多租使用者 SaaS Web 應用程式 連線
必要條件
- Microsoft Entra 租用戶。 如果您沒有帳戶，您可以在我們的 快速入門中建立一個租使用者：在 Microsoft Entra ID 中建立新的租使用者
- 在 Microsoft 身分識別平台 中註冊的應用程式。 如果您沒有帳戶，您可以在我們的快速入門：向 Microsoft 身分識別平台 註冊應用程式。
- 熟悉 Microsoft Entra ID 中的租用。
- 可讓您編輯應用程式程式代碼的整合開發環境 （IDE）。
將註冊更新為多租使用者
根據預設，Microsoft Entra ID 中的 Web 應用程式/API 註冊會在建立時是單一租使用者。 若要進行註冊多租使用者，請登入 Microsoft Entra 系統管理中心 ，然後選取您要更新的應用程式註冊。 開啟應用程式註冊后，選取 [驗證 ] 窗格並流覽至 [支持的帳戶類型 ] 區段。 將設定變更為 任何組織目錄中的 [帳戶]。
在 Microsoft Entra 系統管理中心建立單一租使用者應用程式時，[概觀] 頁面上所列的其中一個專案是 [應用程式識別碼 URI]。 這是應用程式在通訊協定訊息中識別的方式之一，可以隨時新增。 單一租使用者應用程式的應用程式識別碼 URI 在該租使用者內可以是全域唯一的。 相反地，對於多租使用者應用程式，它在所有租用戶中必須具有全域唯一性，這可確保 Microsoft Entra ID 可以在所有租使用者中找到應用程式。
例如，如果租使用者的名稱是 contoso.onmicrosoft.com ，則有效的應用程式識別碼 URI 會是 https://contoso.onmicrosoft.com/myapp。 如果應用程式識別碼 URI 未遵循此模式，請將應用程式設定為多租用戶失敗。
更新程式代碼以將要求傳送至 /common
使用多租使用者應用程式時，應用程式無法立即告知使用者的來源租使用者，因此無法將要求傳送至租使用者的端點。 相反地，要求會傳送至適用於所有 Microsoft Entra 租使用者的通用端點 （https://login.microsoftonline.com/common），做為處理要求的中央中樞。
在 IDE 開啟您的應用程式，並編輯您的程式代碼，並將租使用者識別碼的值變更為 /common。 此端點不是租用戶或簽發者本身。 當 Microsoft 身分識別平台 在端點上/common收到要求時，它會將使用者登入，藉此探索使用者的來源租使用者。 此端點適用於 Microsoft Entra ID 支援的所有驗證通訊協定（OpenID 連線、OAuth 2.0、SAML 2.0、WS-Federation）。
然後，應用程式的登入回應會包含代表使用者的令牌。 令牌中的簽發者值會告訴應用程式用戶來自哪個租使用者。 當回應從 /common 端點傳回時，令牌中的簽發者值會對應至使用者的租使用者。
注意
實際上，多租使用者應用程式的授權單位有2個：
https://login.microsoftonline.com/common適用於處理任何組織目錄中的帳戶的應用程式（任何 Microsoft Entra 目錄）和個人 Microsoft 帳戶（例如 Skype、XBox）。https://login.microsoftonline.com/organizations處理任何組織目錄中帳戶的應用程式（任何 Microsoft Entra 目錄）：
這個檔案中的說明使用 common。 但是，如果您的應用程式不支援 Microsoft 個人帳戶，您可以將它 organizations 取代為 。
更新程式代碼以處理多個簽發者值
Web 應用程式和 Web API 會從 Microsoft 身分識別平台 接收和驗證令牌。 原生用戶端應用程式不會驗證存取令牌，而且必須將它們視為不透明。 他們會改為向 Microsoft 身分識別平台 要求和接收令牌，並執行此動作，以將它們傳送至 API，然後在其中進行驗證。
驗證令牌時，多租使用者應用程式必須執行更多檢查。 多租使用者應用程式已設定為取用來自 /organizations 或 /common 密鑰 URL 的金鑰元數據。 除了令牌中的宣告包含iss租使用者標識碼 （tid） 宣告的一般檢查之外，應用程式必須驗證issuer已發佈元數據中的 屬性是否符合iss令牌中的宣告。 如需詳細資訊，請參閱 驗證令牌。
瞭解使用者和系統管理員同意並進行適當的程式碼變更
若要讓使用者以 Microsoft Entra ID 登入應用程式，應用程式必須在使用者的租使用者中表示。 這可讓組織執行像是在使用者從租使用者登入應用程式時套用唯一原則等動作。 針對單一租使用者應用程式，您可以透過 Microsoft Entra 系統管理中心使用註冊。
對於多租使用者應用程式，應用程式的初始註冊位於開發人員所使用的 Microsoft Entra 租使用者中。 當來自不同租用戶的使用者第一次登入應用程式時，Microsoft Entra ID 會要求他們同意應用程式所要求的許可權。 如果他們同意，則會在使用者的租使用者中建立稱為 服務主體 的應用程式表示法，然後登入可以繼續。 也會在目錄中建立委派，以記錄使用者對應用程式的同意。 如需應用程式 Application 和 ServicePrincipal 物件及其彼此關聯的詳細資訊，請參閱 應用程式對象和服務主體物件。
此同意體驗會受到應用程式要求的許可權影響。 Microsoft 身分識別平台 支援兩種許可權：
- 委派：此許可權會授與應用程式作為用戶可執行之一部分登入使用者的能力。 例如，您可以授與應用程式委派的許可權，以讀取已登入使用者的行事曆。
- 僅限應用程式：此許可權會直接授與應用程式的身分識別。 例如，您可以授與應用程式僅限應用程式的許可權，以讀取租使用者中的用戶清單，而不論誰登入應用程式。
某些許可權可由一般使用者同意，而其他許可權則需要租用戶系統管理員的同意。
若要深入瞭解使用者和系統管理員同意，請參閱 設定管理員同意工作流程。
管理員同意
僅限應用程式的許可權一律需要租用戶系統管理員的同意。 如果您的應用程式要求僅限應用程式許可權，且用戶嘗試登入應用程式，則會顯示錯誤訊息，指出用戶無法同意。
某些委派的許可權也需要租用戶系統管理員的同意。 例如，以登入使用者身分回寫回 Microsoft Entra 識別碼的能力需要租用戶系統管理員的同意。 如同僅限應用程式的許可權，如果一般用戶嘗試登入要求需要系統管理員同意的委派許可權的應用程式，應用程式會收到錯誤。 是否需要系統管理員同意的許可權是由發佈資源的開發人員所決定，而且可以在資源的檔中找到。 Microsoft Graph API 的許可權檔會指出哪些許可權需要管理員同意。
如果您的應用程式使用需要系統管理員同意的許可權，請考慮新增按鈕或連結，讓系統管理員可以起始動作。 您的應用程式為此動作傳送的要求是一般 OAuth2/OpenID 連線 也包含查詢字串參數的prompt=consent授權要求。 一旦管理員同意，且服務主體是在客戶的租使用者中建立之後，後續的登入要求就不需要 prompt=consent 參數。 由於系統管理員已決定可接受要求的許可權，因此不會提示租使用者中的其他使用者從該點向前同意。
租用戶系統管理員可以停用一般使用者同意應用程式的能力。 如果停用此功能，則一律需要系統管理員同意，應用程式才能用於租使用者中。 您可以在 Microsoft Entra 系統管理中心中，使用已停用使用者同意來測試您的應用程式。 在 [企業應用程式>同意和許可權] 中，核取 [不允許使用者同意 ] 選項。
prompt=consent參數也可以供要求不需要系統管理員同意許可權的應用程式使用。 如果應用程式需要有一次租用戶系統管理員「註冊」的體驗，且系統不會提示其他使用者同意，則使用這個範例的範例。
如果應用程式需要系統管理員同意，而系統管理員在沒有傳送參數的情況下 prompt=consent 登入，當系統管理員成功同意應用程式時，它只會套用 至其用戶帳戶。 一般使用者仍然無法登入或同意應用程式。 如果您想要讓租用戶系統管理員在允許其他使用者存取之前探索您的應用程式，這項功能非常有用。
同意和多層式應用程式
您的應用程式可能有多層，每個層都以自己的註冊方式在 Microsoft Entra ID 中表示。 例如，呼叫 Web API 的原生應用程式，或呼叫 Web API 的 Web 應用程式。 在這兩種情況下，用戶端（原生應用程式或 Web 應用程式）要求呼叫資源的許可權（Web API）。 若要讓用戶端成功同意客戶的租使用者，其要求許可權的所有資源都必須存在於客戶的租使用者中。 如果不符合此條件，Microsoft Entra ID 會傳回必須先新增資源的錯誤。
單一租使用者中的多層
如果您的邏輯應用程式是由兩個或多個應用程式註冊所組成，例如個別的用戶端和資源，就可能是問題。 如何先將資源放入外部租使用者？ Microsoft Entra ID 可讓用戶端和資源在單一步驟中同意，藉此涵蓋此案例。 使用者會在同意頁面上看到客戶端和資源所要求的許可權總和。 若要開啟此行為，資源的應用程式註冊必須在其應用程式指令清單中包含用戶端的應用程式識別碼作為 knownClientApplications 。 例如：
"knownClientApplications": ["12ab34cd-56ef-78gh-90ij11kl12mn"]
這會在多租使用者應用程式範例中示範。 下圖提供在單一租用戶中註冊之多層式應用程式的同意概觀。
多個租使用者中的多層
如果應用程式的不同層在不同的租用戶中註冊，就會發生類似的情況。 例如，假設建置呼叫 Exchange Online API 的原生用戶端應用程式。 若要開發原生應用程式，稍後才能讓原生應用程式在客戶的租用戶中執行，Exchange Online 服務主體必須存在。 在此情況下，開發人員和客戶必須購買 Exchange Online，才能在其租使用者中建立服務主體。
如果是 Microsoft 以外的組織所建置的 API，API 的開發人員必須提供一種方式，讓客戶同意應用程式給客戶的租使用者。 建議的設計是讓第三方開發人員建置 API，使其也可以作為 Web 用戶端來實作註冊。 若要這樣做：
- 請遵循先前各節，以確保 API 會實作多租使用者應用程式註冊/程式代碼需求。
- 除了公開 API 的範圍/角色之外，請確定註冊包含「登入和讀取使用者配置檔」許可權（預設提供）。
- 在 Web 用戶端中實作登入/註冊頁面，並遵循 系統管理員同意 指引。
- 一旦使用者同意應用程式，服務主體和同意委派連結就會在其租使用者中建立，而原生應用程式可以取得 API 的令牌。
下圖提供在不同租用戶中註冊之多層式應用程式的同意概觀。
撤銷同意
使用者和系統管理員可以隨時撤銷對應用程式的同意：
- 使用者從其 存取面板 應用程式清單中移除個別應用程式的存取權，以撤銷其存取權。
- 管理員 istrators 使用 移除應用程式來撤銷應用程式的存取權Microsoft Entra 系統管理中心的企業應用程式區段。 選取應用程式並流覽至 [ 許可權] 索引標籤以撤銷存取權。
如果系統管理員同意租使用者中所有使用者的應用程式，使用者就無法個別撤銷存取權。 只有系統管理員可以撤銷存取權，而且只能針對整個應用程式撤銷存取權。
多租使用者應用程式和快取存取令牌
多租使用者應用程式也可以取得存取令牌，以呼叫受 Microsoft Entra ID 保護的 API。 搭配多租使用者應用程式使用 Microsoft 驗證連結庫 （MSAL） 時常見的錯誤，是一開始使用 來要求使用者的 /common令牌、接收回應，然後使用 要求該相同使用者的 /common後續令牌。 因為來自 Microsoft Entra ID 的回應來自租使用者，而不是 /common，MSAL 會將令牌快取為來自租使用者的令牌。 後續呼叫 /common 以取得使用者的存取令牌遺漏快取專案，並提示使用者再次登入。 若要避免遺失快取，請確定已登入使用者的後續呼叫已登入的使用者已對租使用者的端點進行。