Microsoft Entra 條件式存取的開發人員指引

發行項
03/14/2024

您可以使用 Microsoft Entra ID 中條件式存取功能所提供的其中一種方式，來保護您的應用程式及保護服務。條件式存取可讓開發人員和企業客戶以多種方式保護服務，包括：

多重要素驗證
只允許已註冊 Intune 的裝置存取特定服務
限制使用者位置及 IP 範圍

如需條件式存取完整功能的詳細資訊，請參閱什麼是條件式存取一文。

針對建置適用於 Microsoft Entra ID 的應用程式開發人員，本文說明如何使用條件式存取，您也將瞭解存取未控制且可能已套用條件式存取原則的資源的影響。本文也會探索代表流程、Web 應用程式、存取 Microsoft Graph 和呼叫 API 的條件式存取的影響。

假設具備單一和多租使用者應用程式和常見驗證模式的知識。

注意

使用此功能需要 Microsoft Entra ID P1 授權。若要尋找您需求的正確授權，請參閱比較免費、基本和進階版版本的一般可用功能。具有 Microsoft 365 商務版授權的客戶也可以存取條件式存取功能。

條件式存取對應用程式有何影響？

受影響的應用程式類型

在最常見的情況下，條件式存取不會變更應用程式的行為，或要求開發人員進行任何變更。只有在某些情況下，應用程式間接或以無訊息方式要求服務的令牌時，應用程式需要變更程式代碼來處理條件式存取挑戰。這有如執行互動式登入要求一樣簡單。

具體而言，下列案例需要程式碼來處理條件式存取挑戰：

執行代理者流程的應用程式
存取多個服務/資源的應用程式
使用 MSAL.js 的單頁應用程式
呼叫資源的 Web Apps

條件式存取原則可以套用至應用程式，也可以套用至應用程式存取的 Web API。若要深入瞭解如何設定條件式存取原則，請參閱快速入門：使用 Microsoft Entra 條件式存取要求特定應用程式的 MFA。

企業客戶可以根據這種案例，隨時套用及移除條件式存取原則。如需在套用新原則時讓您的應用程式繼續運作，請實作挑戰處理。下列範例說明挑戰處理。

條件式存取範例

某些案例需要程式碼變更才能處理條件式存取，而其他案例則是以原狀運作。以下幾個案例使用條件式存取來執行多重要素驗證，能深入解析差異。

您正在建置單一租使用者 iOS 應用程式，並套用條件式存取原則。應用程式會將使用者登入，且不會要求存取 API。當使用者登入時，會自動叫用原則，而且用戶必須執行多重要素驗證（MFA）。
您正在建置使用中介層服務的原生應用程式來存取下游 API。公司中使用此應用程式的企業客戶會將原則套用至下游 API。當使用者登入時，原生應用程式會要求存取仲介層，並傳送令牌。中介層會執行代理者流程來要求存取下游 API。此時，宣告「挑戰」會呈現至中介層。中介層會將挑戰傳回原生應用程式，而原生應用程式必須符合條件式存取原則。

Microsoft Graph

在條件式存取環境中建置應用程式時，Microsoft Graph 有特殊考慮。一般而言，條件式存取的機制相同，但使用者看到的原則會根據應用程式從圖形要求的基礎數據。

具體而言，所有 Microsoft Graph 範圍都代表可以個別套用原則的一些數據集。由於條件式存取原則會指派特定的數據集，因此 Microsoft Entra ID 會根據 Graph 背後的數據強制執行條件式存取原則，而不是 Graph 本身。

例如，如果應用程式要求下列 Microsoft Graph 範圍，

scopes="ChannelMessages.Read.All Mail.Read"

應用程式可以預期其用戶能夠完成 Teams 和 Exchange 上設定的所有原則。如果授與存取權，某些範圍可能會對應至多個數據集。

符合條件式存取原則

針對數個不同的應用程式拓撲，會在建立會話時評估條件式存取原則。當條件式存取原則在應用程式和服務的數據粒度上運作時，叫用此原則的點會高度取決於您嘗試完成的案例。

當您的應用程式嘗試使用條件式存取原則存取服務時，可能會遇到條件式存取挑戰。此挑戰會編碼在 claims 來自 Microsoft Entra ID 回應的參數中。以下是此挑戰參數的範例：

claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

開發人員可以接受這項挑戰，並將它附加至 Microsoft Entra ID 的新要求。傳遞此狀態會提示使用者執行符合條件式存取原則所需的任何動作。在下列案例中，會說明錯誤的詳細數據，以及如何擷取參數。

案例

必要條件

Microsoft Entra 條件式存取是包含在 Microsoft Entra ID P1 或 P2 中的功能。具有 Microsoft 365 商務版授權的客戶也可以存取條件式存取功能。

特定案例的考慮

下列資訊僅適用於這些條件式存取案例：

執行代理者流程的應用程式
存取多個服務/資源的應用程式
使用 MSAL.js 的單頁應用程式

下列各節將討論更複雜的常見案例。核心作業原則是條件式存取原則會在要求套用條件式存取原則的服務時評估令牌。

案例：執行代理流程的應用程式

在此案例中，我們會逐步解說原生應用程式呼叫 Web 服務/API 的情況。接著，此服務會執行「代理者」流程來呼叫下游服務。在我們的案例中，我們已將條件式存取原則套用至下游服務（Web API 2），並使用原生應用程式，而不是伺服器/精靈應用程式。

App performing the on-behalf-of flow diagram

Web API 1 的初始令牌要求不會提示終端用戶進行多重要素驗證，因為 Web API 1 不一定會叫用下游 API。一旦 Web API 1 嘗試代表 Web API 2 要求令牌，要求就會失敗，因為使用者尚未使用多重要素驗證登入。

Microsoft Entra ID 會傳回 HTTP 回應，其中包含一些有趣的數據：

注意

在此實例中，這是多重要素驗證錯誤描述，但有各種 interaction_required 可能與條件式存取有關。

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API 2 App/Client ID>'.
claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

在 Web API 1 中，我們會攔截錯誤 error=interaction_required，並將挑戰傳回 claims 傳統型應用程式。此時，傳統型應用程式可以進行新的 acquireToken() 呼叫，並將挑戰附加 claims為額外的查詢字串參數。這個新的要求需要使用者執行多重要素驗證，然後將這個新的令牌傳回 Web API 1，並完成代理流程。

若要試用此案例，請參閱我們的 .NET 程式代碼範例。它示範如何將宣告挑戰從 Web API 1 傳回至原生應用程式，並在用戶端應用程式內建構新的要求。

案例：應用程式存取多個服務

在此案例中，我們會逐步解說 Web 應用程式存取兩個服務的情況，其中一個服務已指派條件式存取原則。視您的應用程式邏輯而定，您的應用程式可能不需要存取這兩個 Web 服務的路徑。在此案例中，您要求令牌的順序在用戶體驗中扮演重要角色。

假設我們有 Web 服務 A 和 B，而 Web 服務 B 已套用條件式存取原則。雖然初始互動式驗證要求需要這兩項服務的同意，但在所有情況下都不需要條件式存取原則。如果應用程式要求 Web 服務 B 的令牌，則會叫用原則，而 Web 服務 A 的後續要求也會成功，如下所示。

App accessing multiple-services flow diagram

或者，如果應用程式一開始要求 Web 服務 A 的令牌，使用者就不會叫用條件式存取原則。這可讓應用程式開發人員控制用戶體驗，而不會強制在所有情況下叫用條件式存取原則。棘手的情況是應用程式稍後要求 Web 服務 B 的令牌。此時，用戶必須符合條件式存取原則。當應用程式嘗試時 acquireToken，它可能會產生下列錯誤（如下圖所示）：

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API App/Client ID>'.
claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

App accessing multiple services requesting a new token

如果應用程式使用 MSAL 連結庫，則一律會以互動方式重試無法取得令牌。發生此互動式要求時，用戶有機會遵守條件式存取。除非要求是 AcquireTokenSilentAsync ，否則 PromptBehavior.Never 應用程式必須執行互動式 AcquireToken 要求，讓用戶有機會遵守原則，否則這是 true。

案例：使用單頁應用程式（SPA）使用 MSAL.js

在此案例中，我們會逐步解說單頁應用程式（SPA）使用 MSAL.js 呼叫條件式存取受保護 Web API 的情況。這是簡單的架構，但有一些細微差別，需要在條件式存取周圍開發時納入考慮。

在MSAL.js中，有幾個函式會取得令牌： acquireTokenSilent()、 acquireTokenPopup()和 acquireTokenRedirect()。

acquireTokenSilent() 可以用來以無訊息方式取得存取令牌，這表示在任何情況下都不會顯示UI。
acquireTokenPopup() 和 acquireTokenRedirect() 都用來以互動方式要求資源的令牌，這表示它們一律會顯示登入 UI。

當應用程式需要存取權杖來呼叫 Web API 時，它會嘗試 acquireTokenSilent()。如果令牌已過期，或我們需要遵守條件式存取原則，則 acquireToken 函式會失敗，且應用程式會使用 acquireTokenPopup() 或 acquireTokenRedirect()。

Single-page app using MSAL flow diagram

讓我們逐步解說條件式存取案例的範例。使用者剛登陸網站，而且沒有會話。我們會執行 loginPopup() 呼叫，取得沒有多重要素驗證的標識符令牌。然後，使用者會叫用按鈕，要求應用程式向 Web API 要求數據。應用程式會嘗試執行 acquireTokenSilent() 呼叫，但失敗，因為使用者尚未執行多重要素驗證，且必須符合條件式存取原則。

Microsoft Entra ID 會傳回下列 HTTP 回應：

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API App/Client ID>'.

應用程式需要攔截 error=interaction_required。然後，應用程式就可以在同一 acquireTokenPopup() 個資源上使用或 acquireTokenRedirect() 。使用者被迫執行多重要素驗證。使用者完成多重要素驗證之後，應用程式會針對要求的資源發出新的存取令牌。

若要試用此案例，請參閱我們的 React SPA 呼叫Node.js Web API 使用代理流程程式碼範例。此程式代碼範例會使用您稍早向 React SPA 註冊的條件式存取原則和 Web API 來示範此案例。它示範如何正確處理宣告挑戰，並取得可用於 Web API 的存取令牌。

另請參閱

若要深入瞭解功能，請參閱 Microsoft Entra ID 中的條件式存取。
如需更多 Microsoft Entra 程式代碼範例，請參閱範例。
如需 MSAL SDK 及存取參考文件的詳細資訊，請參閱 Microsoft 驗證連結庫概觀。
若要深入瞭解多租使用者案例，請參閱如何使用多租使用者模式登入使用者。
深入了解條件式存取和保護對IoT應用程式的存取。