使用单独的前端和后端应用程序进行 Azure AD 代表身份验证

Question

我觉得我在这里可能有点发疯。

我有一个基本架构，其中包含一个前端反应应用 (SPA Auth)，它与后端 GraphQL Nodejs API 服务 (Protected Web API Auth) 通信，托管在 Azure 中并使用 Azure AD 进行身份验证。

• 前端访问令牌需要 User.Read 访问 azure 图，以及访问后端公开范围
• 后端公开 API 和单一访问范围
• 后端还需要 User.Read 代表用户访问 azure graph

我一直在尝试将身份验证配置为使用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。

在 On-Behalf-Of 文档中，它说明了以下有关使用 /.default 范围的内容 -

/.default 和组合同意

中间层应用程序将客户端添加到其清单中的已知客户端应用程序列表中，然后客户端可以触发其自身和中间层应用程序的组合同意流。在 Microsoft 标识平台终结点上，这是使用 /.default 范围完成的。当使用已知的客户端应用程序和 /.default 触发同意屏幕时，同意屏幕将显示客户端对中间层 API 的权限，并请求中间层 API 所需的任何权限。用户同意这两个应用程序，然后 OBO 流程开始工作。

我已经尝试了应用注册中的各种配置组合以及范围请求的不同组合，但我根本无法使其按预期运行；提示似乎不包括合并同意。 我让它发挥作用的唯一方法是手动向 User.Read 的后端应用程序提供管理员同意，这似乎是一个 hack，我更愿意正确配置它以征求用户同意。

如果有人之前配置过类似的东西（似乎是预期的用例），请告诉我你是如何工作的，包括类似的配置

• 前端服务的应用注册配置（例如 api 权限集）
• 后端服务的应用注册配置（例如公开范围、api 权限、授权客户端应用程序）
• 各种身份验证请求所请求的范围

在这个阶段，我将不得不恢复到可能使用一个应用程序注册并在前端和后端之间共享相同的访问令牌，尽管我个人认为这似乎是一个更糟糕的解决方案。

Answer 1

弄清楚了，我的主要问题是我将已知客户端应用程序列表与授权客户端应用程序混淆了。

授权的客户端应用程序显示在 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