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

適用於： 員工租戶 （瞭解更多資訊）

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

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

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

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

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

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

受影響的應用程式類型

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

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

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

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

視案例而定，企業客戶可以隨時套用和移除條件式存取原則。 若要讓應用程式在套用新原則時繼續運作，請實作挑戰處理。 下列範例說明挑戰處理。

條件式存取範例

有些案例需要程式代碼變更來處理條件式存取，而其他案例則如常運作。 以下是一些使用條件式存取來執行多重要素驗證的案例，可深入了解差異。

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

Microsoft Graph

Microsoft Graph 在條件式存取環境中建置應用程式時有特殊考慮。 一般而言，條件式存取的機制通常是相同的，但使用者看到的政策會根據應用程式從 Graph (圖表) 要求的基礎數據而有所不同。

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

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

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

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

符合條件式存取原則

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

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

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），並使用原生應用程式，而不是伺服器/精靈應用程式。

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

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 multifactor 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 的後續要求也會成功，如下所示。

或者，如果應用程式一開始要求 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 multifactor authentication to access '<Web API App/Client ID>'.
claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

如果應用程式使用 MSAL 程式庫，遇到無法取得令牌的情況時，會始終以互動方式進行重試。 當發生此互動式要求時，最終用戶有機會符合條件式存取。 除非要求是 AcquireTokenSilentAsync 或 PromptBehavior.Never，否則應用程式必須執行互動式 AcquireToken 要求，以便給予用戶遵守政策的機會，這情況屬實。

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

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

在 MSAL.js中，有一些函式可取得權杖： acquireTokenSilent()、 acquireTokenPopup()和 acquireTokenRedirect()。

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

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

讓我們來看一個條件式存取案例的例子。 使用者剛進入網站，而且沒有連線。 我們執行 loginPopup() 呼叫，取得不需要多重驗證的 ID 憑證。 然後，使用者會叫用按鈕，要求應用程式向 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 multifactor 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標識符中的條件式存取。
• 如需更多Microsoft Entra 程式代碼範例，請參閱 範例。
• 如需 MSAL SDK 及存取參考文件的詳細資訊，請參閱 Microsoft驗證連結庫概觀。
• 若要深入瞭解多租使用者案例，請參閱 如何使用多租使用者模式登入使用者。
• 深入了解 條件式存取和保護對IoT應用程式的存取。