使用 Azure Logic Apps 中的 Easy Auth （App Service 驗證） 保護交談代理程式工作流程 （預覽版）

適用於：Azure Logic Apps (標準)

這很重要

此功能處於預覽狀態，且受限於 Microsoft Azure 預覽版的補充使用規定。

客服專員工作流程擴展了整合選項，因為它們可以與更多樣化的呼叫者交換訊息，例如人員、客服專員、模型內容通訊協定 （MCP） 伺服器和用戶端、工具代理程式和外部服務。 雖然非客服專員工作流程與一組小型、已知和固定的呼叫者互動，但客服專員呼叫者可能來自動態、未知和不受信任的網路。 因此，您必須驗證並強制執行每個呼叫者的權限。

若要協助保護生產中的對話客服專員工作流程，請設定 Easy Auth 以驗證和授權想要與對話客服專員互動的來電者或人員。 Easy Auth 也稱為 App Service 驗證，提供下列功能供您使用：

• 為每個呼叫者要求提供經過驗證的身分識別。
• 將連線指派給每個使用者。
• 強制執行條件式存取原則。
• 發出可撤銷的認證。
• 根據最低權限原則、 角色和 範圍授與許可權。
• 在 Azure 入口網站外部提供外部聊天用戶端，讓人員可以與您的交談代理程式互動。

這些措施可讓您在細粒度層級驗證和授權每個呼叫者，並在需要時快速撤銷存取權。 如果沒有這些控制項，您可能會面臨不受控制的存取、洩漏的秘密 （例如共用存取簽章 （SAS） URL 和存取金鑰）、弱稽核追蹤和其他安全性隱患。

Easy Auth 會與 Microsoft Entra ID 搭配使用，做為個別的安全性層，以提供符合您需求的內建驗證和授權功能。 透過在工作流程之外運作安全強制執行，您可以更專注於開發商務邏輯。 這種關注點的分離使代理程式工作流程更簡單、更容易建置、偵錯、操作、監控、維護、治理和稽核。

非代理程式工作流程安全性通常涉及靜態 SAS、輪替秘密和網路界限控制，例如存取限制、IP 允許清單、服務標籤、虛擬網路整合和私人端點。 使用代理程式工作流程，您可以圍繞使用者、受控識別、服務主體及其範圍和角色來設計授權。 此方法可實現更安全的全球覆蓋範圍，但仍允許下游工作流程動作尊重精細的權限。

本指南說明如何建立應用程式註冊，然後為您的標準邏輯應用程式資源進行 Easy Auth 設定，其中可以包含代理工作流程及非代理工作流程。

這很重要

Easy Auth 會將組態資訊儲存在邏輯應用程式資源的基礎應用程式設定中，例如 WEBSITE_AUTH_ENABLED、WEBSITE_AUTH_DEFAULT_PROVIDER 和 MICROSOFT_PROVIDER_AUTHENTICATION_SECRET。 除非您想要使用 ARM 範本、Bicep 範本或 Terraform 範本來設定自動化，否則請勿手動編輯這些設定。

如需詳細資訊，請參閱下列文章：

• 使用 Easy Auth 為代理工作流程提供內建身份驗證和授權
• 在 Microsoft Entra ID 中註冊應用程式

先決條件

• Azure 帳戶和訂閱。 如果您沒有訂用帳戶，請註冊一個免費的 Azure 帳戶。

• 您的 Azure 帳戶上的 Microsoft Entra 應用程式開發人員 內建角色，用於建立應用程式註冊。

• 已部署的標準邏輯應用程式資源，具有交談式代理程式工作流程。

  如需詳細資訊，請參閱 在 Azure Logic Apps 中建立聊天互動的交談代理程式工作流程。

• 邏輯應用程式資源上的 Azure 參與者 角色 或更高角色，並有權限使用 Microsoft Entra 為目標租用戶建立應用程式註冊。

  這很重要

  若要設定 Easy Auth，請確定您具有較高層級的 Azure 參與者 角色，這與 Logic Apps 標準參與者 角色不同。

• （選用）選擇是否只支援具備互動式登入程序的使用者流程，或也支援使用受管理的識別或服務主體的呼叫者。

  如需詳細資訊，請參閱 Azure App Service 和 Azure Functions 中的驗證和授權。

• （選用）自訂網域 （如果您想要強制執行該網域的特定 重新導向 URI ）。

建立應用程式註冊

若要以最佳方式開始 Easy Auth 設定，請直接從邏輯應用程式資源在 Microsoft Entra ID 中建立新的應用程式註冊。 如果您必須改為重複使用現有的應用程式註冊，則必須 更新應用程式註冊 ，才能與 Easy Auth 和 Azure 用戶端搭配使用。

1. 在 Azure 入口網站中，開啟您的標準邏輯應用程式資源。

2. 在資源側邊欄功能表的 [設定] 底下，選取 [驗證]。

3. 在 [驗證] 頁面上，選取 [新增身分識別提供者]。

   

   「 驗證」 頁面現在會顯示「 基本」 標籤，用於設定身分識別提供者。

4. 在 [基本] 索引標籤的 [身分識別提供者] 中，針對 Microsoft Entra ID 選取 Microsoft 。

5. 在 應用程式註冊 區段中，針對 應用程式註冊類型，選取 （建議用於交談代理程式） 建立新的應用程式註冊，這會顯示此選項的對應選項。

6. 為您的應用程式註冊提供唯一的顯示名稱，例如： agent-logic-app-reg-prod

7. 針對 [使用者指派的受控識別]，選取 [ 建立新的使用者指派的受控識別]。

   您可以透過提供名稱或選取現有身分來建立新身分。

8. 針對 [支援的帳戶類型]，選取 [目前租用戶 - 單一租用戶 ]，除非您想要刻意接受其他租用戶。

   單一租用戶設定僅指目前組織目錄中的帳戶。 因此，此目錄中的所有使用者和來賓帳戶都可以使用您的應用程式或 API。 例如，如果您的目標對象是組織內部，請使用此設定。

   下列範例顯示應用程式註冊的外觀：

   

   這很重要

   除非您已設定明確的治理和條件式存取原則，否則請勿選擇 [ 任何 Microsoft Entra 目錄 - 多租用戶]。

   如需詳細資訊，請參閱下列文章：

   • Azure 治理概觀
   • 在 Azure 中設定治理
   • 什麼是條件式存取？

9. 在 [其他檢查] 底下，選取下列值 （如果尚未選取）：

   Setting	價值觀
   用戶端應用程式需求	僅允許來自此應用程式本身的請求
   身分識別需求	允許來自特定身分的請求
   允許的身分識別	只有在選取 允許來自特定身分的請求時 才會出現。 預設預先填入的值是代表目前使用者 （也就是您自己） 的物件 ID。 您可以透過下列方式更新此值： - 包含其他開發人員或使用者的物件 ID。 - 使用群組宣告來包含特定群組，而不是個別物件識別碼。 - 選取邏輯應用程式資源的現有應用程式註冊。 如果這樣做，請務必 更新應用程式註冊 ，以便與 Easy Auth 完美配合。 如需詳細資訊，請參閱 使用內建授權原則。
   租用戶需求	僅允許來自簽發者租用戶的要求

10. 略過 [ 排除的路徑 ] 區段。

11. 或者，在 [App Service 驗證設定] 底下，檢閱下列設定並採取適當的動作：

    Setting	動作
    限制存取	除非您打算允許某些已驗證的端點，否則請選取 [ 需要驗證 ] 以封鎖所有匿名要求。
    未驗證的要求	根據呼叫者是否為代理程式或基於代理程式，選取 [HTTP 302 找到重新導向：建議代理程式使用]。

12. 完成時，請選取 [ 新增 ] 以完成新增身分識別提供者。

    Azure 會建立應用程式註冊、更新您的應用程式設定，並啟用 Easy Auth 執行階段。 當 Azure 完成時，邏輯應用程式 的 [驗證] 頁面會將 Microsoft 列為身分識別提供者。 用戶端和呼叫者現在必須驗證其身分。 您的邏輯應用程式會如預期般拒絕未經驗證的客戶端和呼叫者，並在當要求不包含有效的權杖時發出 302 已找到重新導向 回應或 401 未授權 回應。

    完成建立應用程式註冊之後，請盡可能將邏輯應用程式設定保持在最低限度，直到您可以確認驗證如預期般運作為止。 您稍後可以移至應用程式註冊資源上的下列頁面，以新增您想要強制執行的任何許可範圍或應用程式角色：

    • 在應用程式註冊側邊欄的 [管理] 底下，選取 [ 公開 API ] 以新增許可權範圍。 如需詳細資訊，請參閱 新增範圍。

    • 在應用程式註冊側邊欄的 [管理] 底下，選取 [ 應用程式角色] 以指派應用程式角色。 如需詳細資訊，請參閱 指派應用程式角色。

    或者，您可以檢閱下一節中的對應步驟， 更新現有的應用程式註冊。

13. 若要檢查您的應用程式註冊是否已正確設定，請參閱測試 和驗證 Easy Auth 設定。

更新現有的應用程式註冊

如果您必須重複使用與另一個 API 或舊版原型共用的現有應用程式註冊，請遵循下列步驟來檢閱和調整指定的設定，以便應用程式註冊可以與 Easy Auth 和代理程式用戶端順利運作。

1. 在 Azure 入口網站 搜尋方塊中，尋找並選取 Microsoft Entra ID。

2. 在側邊欄功能表的 [管理] 底下，選取 [ 應用程式註冊]，然後尋找並選取您的應用程式註冊。

3. 在應用程式註冊側邊欄功能表上，展開 管理。

4. 在 [管理] 底下，選取 [品牌 & 屬性]，然後確認首頁 URL 設定會指定邏輯應用程式的網站 URL。

   備註

   首頁 URL 是後端或代理程式的 API 中的選填項。 只有在端使用者需要登入或文件頁面時，才設定此值。 Token 重新導向不會使用此值。

5. 在 [管理] 底下，選取 [驗證]。

   1. 在 Platform configurations（平台組態設定）下，確定 Web 條目存在。

   2. 在 Web 項目中的 重新導向 URI 下，尋找預先填入的 Easy Auth（App Service Authentication）回呼 URI，其遵循下列語法：

      https://<logic-app-name>.azurewebsites.net/.auth/login/aad/callback

      除非您的案例需要公開自訂 API 應用程式識別碼，否則請保留此預設值。 此回呼 URI 是預設 存取權杖 對象 ，並指定哪些資源可以接受來自想要存取這些資源的用戶端的存取權杖。

      允許權杖對象背後的目的，是僅尊重為這些資源提供有效權杖的要求。 存取權杖要求涉及兩方：要求權杖的用戶端和接受權杖的資源。 收件者亦稱為權杖「對象」，在此案例中是您的邏輯應用程式。

      如需詳細資訊，請參閱 什麼是重新導向 URI？

   3. 如果 Azure 未預先填入 [ 重新導向 URI] 設定，請使用您的邏輯應用程式名稱手動輸入 URI，例如：

      https://my-chatbox-logic-app.azurewebsites.net/.auth/login/aad/callback

      這很重要

      除非您裝載互動式前端，否則請勿使用自訂重新導向 URI。

   4. 忽略 前端通道登出 URL 設定。

   5. 針對 隱性授權及混合流程，請選擇以下兩個選項：

      • 存取令牌 （用於隱式流程）
      • ID 令牌 （用於隱式與混合流程）

      如需詳細資訊，請參閱下列文件：

      • Microsoft 身分識別平台和 OAuth 2.0 隱含授與流程
      • 要求識別碼權杖 (混合流程)

   6. 在 [支援的帳戶類型] 底下，選取符合您業務需求的選項。

      在大多數情況下，請選擇 僅限於此組織目錄中的帳戶（Microsoft 專用 - 單一租戶）。 針對多租用戶選項，請確定您已設定明確的 Azure 治理和條件式存取原則。 如需這些選項的詳細資訊，請參閱 依支援的帳戶類型進行驗證差異。

   7. 在進階設定中，針對允許公用用戶端流程，將否設定保留用於啟用指定的行動及桌面流程。

      當原生公用用戶端必須使用裝置或驗證碼避免資源擁有者密碼認證 (ROPC) 流程時，就會發生例外狀況。

   8. 完成時，請選取 [儲存]。

6. 在 [管理] 下，選取 [ 憑證與秘密]。 在 [ 同盟認證] 索引標籤上，設定具有邏輯應用程式存取權的新使用者指派受控識別，以便您可以在 應用程式註冊上使用受控識別作為同盟識別認證。

   如果您沒有使用者指定的受管理身分具有邏輯應用程式存取權，請遵循下列步驟：

   1. 建立使用者指派的受控識別。
   2. 將使用者指派的身分識別新增至您的邏輯應用程式。
   3. 在應用程式註冊時，將使用者指派的身分識別設定為同盟身分認證。

7. 或者，如果您需要設定 宣告 ，例如角色、範圍、使用者群組或 XMS_CC，請遵循下列步驟：

   1. 在 [管理] 底下，選取 [令牌組態]。

   2. 在 [選擇性宣告] 區段中，新增您的宣告。

      備註

      若要避免權杖膨脹，請設定角色或範圍檢查，而不是大型的群組宣告。

8. 在 [管理] 底下，選取 [API 權限]，然後遵循下列步驟：

   1. 在 [已設定的權限] 底下，選取 [新增權限]。
   2. 在 [ 要求 API 許可權 ] 窗格的 [ Microsoft API ] 索引標籤上，尋找並選取 [ Microsoft Graph]。
   3. 針對許可權類型，選取 [委派的許可權]。
   4. 在 [選取權限 ] 方塊中，輸入 User.Read。
   5. 在 [許可權] 欄中，展開 [使用者]，然後選取 [User.Read] 許可權。

   如需詳細資訊，請參閱 新增存取 Microsoft Graph 的許可權。

9. 或者，在 [管理] 底下，選取 [ 公開 API]，以便定義和公開許可權範圍。

   針對 應用程式識別碼 URI 設定，預先填入的 URI 是唯一識別碼，代表您的邏輯應用程式資源作為存取權杖中的對象，並使用下列格式：

   api://<application-client-ID>

   在此 API 定義的範圍 區段中，如果您只想依賴驗證角色和對象，則不需要定義或公開任何許可權範圍。 不過，如果您想要 Azure 用戶端要求委派的許可權，請遵循下列步驟來定義這些範圍：

   1. 選取 [ 新增範圍 ]，並提供下列資訊：

      Setting	為必填項目	價值觀
      範圍名稱	Yes	user_impersonation
      誰可以同意	Yes	系統管理員和使用者
      管理員同意顯示名稱	Yes	當租用戶系統管理員提供同意範圍時，在同意訊息中顯示的權限範圍標籤或名稱。 例如： 存取 <邏輯應用程式名稱>
      管理員同意定義	Yes	租用戶系統管理員在同意畫面上展開範圍時，同意畫面所顯示的權限範圍的詳細描述。 例如： 允許應用程式代表登入的使用者存取 <邏輯應用程式名稱> 。
      使用者同意顯示名稱	否	當使用者同意此範圍時，同意畫面會顯示的許可範圍的選擇性名稱。 例如： 存取 <邏輯應用程式名稱>
      使用者同意定義	否	當使用者在同意畫面上展開範圍時，系統顯示的權限範圍的詳細說明是可選的。 例如： 允許應用程式代表您存取 <logic-app-name> 。
      州	Yes	Enabled

   2. 完成後，選取 [新增範圍]。

   3. 在 [範圍] 清單中，檢閱更新的範圍設定，以確認它們如預期般顯示。

10. 當您完成更新應用程式註冊時，請移至您的標準邏輯應用程式資源。

11. 在邏輯應用程式側邊欄的 [設定] 底下，選取 [驗證]。

12. 在 [驗證 ] 頁面的 [ 驗證設定] 旁邊，選取 [編輯] 以檢閱設定。 在 [編輯驗證設定 ] 窗格中，確認下列值：

Setting	價值觀	Description
App Service 驗證	Enabled	您的邏輯應用程式已設定並啟用簡易驗證 (Easy Auth)。
限制存取	需要驗證	用戶端和呼叫者必須驗證其身分。
未驗證的要求	Yes	您的邏輯應用程式會如預期般拒絕未經驗證的客戶端和呼叫者，並在當要求不包含有效的權杖時發出 302 已找到重新導向 回應或 401 未授權 回應。

測試和驗證 Easy Auth 設定

設定 Easy Auth 之後，Azure 入口網站中工作流程 [ 聊天 ] 頁面上的內部聊天介面將無法使用。 相反地，您必須使用 Azure 入口網站外部可用的外部聊天用戶端，與交談代理程式互動。 若要確認 Easy Auth 如預期般運作，請依照下列步驟在外部聊天用戶端中執行測試：

1. 在設計工具工具列或工作流程側邊欄上，選取 聊天。

   內部聊天介面不再出現在 聊天 頁面上。

2. 在 [基本] 區段中，選取 [聊天用戶端 URL ] 連結，這會開啟新的瀏覽器索引標籤。

3. 在權限要求提示中，提供您的同意，然後接受要求。

   

   瀏覽器頁面會重新整理，並顯示外部聊天用戶端的介面。

   小提示

   您也可以將聊天用戶端 URL 內嵌在 iFrame HTML 元素 中，以搭配您想要提供聊天用戶端的網站使用，例如：

   <iframe src="https:/<logic-app-name>.azurewebsites.net/api/agentsChat/<workflow-name>/IFrame" title="<chat-client-name>"></iframe>

4. 在外部聊天介面中，開始或繼續與您的對話客服人員互動。

5. 若要檢閱工作流程的執行歷程記錄，請遵循下列步驟：

   1. 返回 Azure 入口網站中的工作流程。

   2. 在工作流程側邊欄的 工具 下，選取 執行歷程記錄，然後選取最新的工作流程執行。

   3. 在監視檢視中，確認執行歷程記錄和作業狀態如預期般顯示。

疑難排解 Easy Auth 測試期間的錯誤

下表說明您在設定 Easy Auth 時可能遇到的常見問題、可能的原因，以及您可以採取的動作：

問題或錯誤	可能的原因	動作
401 附有參考對象的 invalid_token + error_description	存取權杖對象與指定的允許權杖對象之間存在不一致。	請確定存取權杖對象與允許的權杖對象相符。
403 禁止	可能表示找不到要求的工作流程或代理程式。	檢查工作流程中的動作是否有授權問題。

在工作流程中使用身分識別

當 Easy Auth 驗證請求時，Easy Auth 會根據身分提供者將身分資料插入請求標頭。 您的邏輯應用程式會使用這些標頭來驗證呼叫端。

如需詳細資訊，請參閱下列文章：

• App Service 的 OAuth 權杖
• 教學課程：在 Azure App Service 中端對端驗證和授權使用者

相關內容

• AI 代理工作流程中的身份驗證和授權