驗證概觀
Fabric 工作負載依賴與 Microsoft Entra ID 整合以進行驗證和授權。
工作負載與其他 Fabric 或 Azure 元件之間的所有互動都必須附帶適當的驗證支援，以處理接收或發送的請求。 已傳送的權杖必須正確產生，而且已接收的權杖也必須正確驗證。
建議您先熟悉 Microsoft 身分識別平台，再開始使用 Fabric 工作負載。 也建議您參閱 Microsoft 身分識別平台最佳做法和建議。
流程
從工作負載前端到工作負載後端
此類通訊的一個例子是任何資料平面 API。 此通訊是透過主體權杖來完成的 (委派的權杖)。
如需如何在工作負載 FE 中取得權杖的資訊，請參閱驗證 API。 此外，請確保您在後端驗證和授權概觀中查看權杖驗證的相關內容。
從網狀架構後端到工作負載後端
此類通訊的一個範例是建立工作負載項目。 此通訊是使用 SubjectAndApp 令牌來完成，這是包含應用程式令牌和主體令牌結合的特殊令牌（請參閱 後端驗證和授權概觀 以深入瞭解此令牌）。
若要讓此通訊能夠運作，使用此通訊的用戶必須同意 Microsoft Entra 應用程式。
從工作負載後端到網狀架構後端
這是透過 SubjectAndApp 權杖來處理工作負載控制 API (例如，ResolveItemPermissions)，或是使用主體權杖 (用於其他 Fabric API) 來完成的。
從工作負載後端到外部服務
此類通訊的一個範例是寫入 Lakehouse 檔案。 這會使用主體權杖或應用程式權杖來完成，視 API 而定。
如果您打算使用主體權杖與服務通訊，請確定您已熟悉代表流程。
請參閱驗證教學課程，以設定您的環境來使用驗證。
驗證 JavaScript API
Fabric 前端提供適用於 Fabric 工作負載的 JavaScript API，以便在 Microsoft Entra ID 中獲取其應用程式的權杖。 使用驗證 JavaScript API 之前，請確定您已檢閱驗證 JavaScript API 文件。
同意
若要了解為何需要同意，請檢閱 Microsoft Entra ID 中的使用者和管理員同意。
同意如何在 Fabric 工作負載中運作？
若要授與特定應用程式的同意，Fabric FE 會建立以工作負載的應用程式 ID 設定的 MSAL 執行個體，並要求提供範圍的權杖 (additionalScopesToConsent - 請參閱 AcquireAccessTokenParams)。
當要求具有特定範圍的工作負載應用程式權杖時，Microsoft Entra ID 會在缺失時顯示快顯同意，然後將快顯視窗重新導向至應用程式中設定的重新導向 URI。
重新導向 URI 通常位於與要求權杖的頁面相同的網域中，因此，頁面可以存取快顯並將其關閉。
在我們的案例中，它不是在相同的網域中，因為 Fabric 正在要求權杖，而工作負載的重新導向 URI 不在 Fabric 網域中，因此當同意對話方塊開啟時，它必須在重新導向之後手動關閉 - 我們不會使用 redirectUri 中傳回的程式碼，因此我們只會將它自動關閉 (當 Microsoft Entra ID 將快顯重新導向至重新導向 URI 時，它會關閉)。
您可以在檔案 index.ts 中看到重新導向 URI 的程式碼/設定。 您可以在前端資料夾下的 Microsoft-Fabric-workload-development-sample 中找到此檔案。
以下是應用程式「我的工作負載應用程式」及其在進行驗證設定時所設定的相依性 (儲存體和 Power BI) 的同意快顯的範例：
