使用單獨的前端和后端應用程序的 Azure AD 代表身份驗證

Question

我覺得我在這里可能有點生氣。

我有一個具有前端反應應用程序 ( SPA Auth ) 的基本架構，它與后端 GraphQL Nodejs API 服務 ( Protected Web API Auth ) 通信，托管在 Azure 中並使用 Azure AD 進行身份驗證。

• 前端訪問令牌需要 User.Read 訪問 azure 圖形，以及訪問后端公開范圍
• 后端公開一個 API 和單一的訪問范圍
• 后端還需要 User.Read 代表用戶訪問 azure 圖形

我一直在嘗試配置身份驗證以使用On-Behalf-Of Flow 。

1. react 應用程序使用自己的應用程序注冊詳細信息成功檢索了訪問令牌
2. 訪問令牌隨每個 GraphQL 請求提供給后端服務
3. 后端服務驗證提供給它的訪問令牌
4. 后端服務通過 On-Behalf-Of grant_type urn:ietf:params:oauth:grant-type:jwt-bearer請求它自己的訪問令牌

這一切都有效，除了我無法解決這個問題 -

用戶或管理員未同意使用名為“service-cbcity-api”的 ID 為“9b56c153-be42-499a-a41a-20176ed2ce69”的應用程序。 為此用戶和資源發送交互式授權請求。

基本上我無法成功配置應用程序注冊和令牌請求，以確保當后端請求它的令牌時，它被允許代表最初經過身份驗證的用戶調用 User.Read。

在代表文檔中，它說明了有關使用/.default范圍的以下內容 -

/.default 和聯合同意

中間層應用程序將客戶端添加到其清單中的已知客戶端應用程序列表中，然后客戶端可以為自身和中間層應用程序觸發組合同意流。 在 Microsoft 標識平台端點上，這是使用 /.default 范圍完成的。 當使用已知客戶端應用程序和 /.default 觸發同意屏幕時，同意屏幕將顯示客戶端對中間層 API 的權限，並請求中間層 API 所需的任何權限。 用戶對這兩個應用程序都表示同意，然后 OBO 流程就起作用了。

我已經嘗試了應用程序注冊中的各種配置組合以及范圍請求的不同組合，但我根本無法使其按預期運行； 提示似乎不包括合並同意。 我讓它發揮作用的唯一方法是手動向 User.Read 的后端應用程序提供管理員同意，這似乎是一個黑客，我更願意正確配置它以征求用戶同意。

如果有人之前配置過類似的東西（似乎是預期的用例），請告訴我你是如何讓它工作的，包括像這樣的配置

• 前端服務的應用注冊配置（例如 api 權限集）
• 后端服務的應用程序注冊配置（例如公開范圍、api 權限、授權的客戶端應用程序）
• 各種身份驗證請求請求的范圍

在這個階段，我將不得不恢復到可能使用一個應用程序注冊並在前端和后端之間共享相同的訪問令牌，盡管就我個人而言這似乎是一個更糟糕的解決方案。

Answer 1

想通了，我的主要問題是我將known client applications list與Authorized client applications混淆了。

授權客戶端應用程序存在於 UI 中，可從公開 API 區域進行配置 -

但是，這與已知的客戶端應用程序不同，后者是只有在您編輯清單時才能找到的設置 -

這個謎題的關鍵部分是——

• 將您的前端應用客戶端 ID 添加到后端應用注冊清單中的 knownClientApplications
• 使用前端應用登錄時，您的范圍需要為{{api_clientid}}/.default ，其中{{api_clientid}}是后端應用注冊的客戶端 ID

這將在用戶同意時向用戶顯示您在后端應用程序注冊中配置的 API 權限，並允許您的后端進程使用 OBO 流檢索 AccessToken。

對於它的價值，這是幫助我意識到我需要更新清單的教程，並為我提供了有關確切 OAUTH 請求格式的指導 - https://github.com/Azure-Samples/active-directory-dotnet-native- aspnetcore-v2/tree/master/2.%20Web%20API%20now%20calls%20Microsoft%20Graph#how-to-deploy-this-sample-to-azure