gpt4 book ai didi

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

转载 作者:行者123 更新时间:2023-12-02 22:59:17 29 4
gpt4 key购买 nike

我觉得我可能有点生气了。

我的基本架构具有前端 React 应用程序 ( SPA Auth ),该应用程序与后端 GraphQL Nodejs API 服务 ( Protected Web API Auth ) 通信,托管在 Azure 中并使用 Azure AD 进行身份验证。

  • 前端访问 token 需要 User.Read 对 azure graph 的访问权限,以及对后端公开范围的访问权限
  • 后端公开 API 和单一访问范围
  • 后端还需要代表用户对 azure graph 进行 User.Read 访问

我一直在尝试将身份验证配置为使用 On-Behalf-Of Flow .

  1. React 应用使用其自己的应用注册详细信息成功检索访问 token
  2. 访问 token 会通过每个 GraphQL 请求提供给后端服务
  3. 后端服务验证提供给它的访问 token
  4. 后端服务通过 On-Behalf-Of grant_type 请求它自己的访问 token urn:ietf:params:oauth:grant-type:jwt-bearer

这一切都有效,除了我无法解决这个问题 -

The user or administrator has not consented to use the application with ID '9b56c153-be42-499a-a41a-20176ed2ce69' named 'service-cbcity-api'. Send an interactive authorization request for this user and resource.

基本上,我无法成功配置应用程序注册和 token 请求,以确保当后端请求其 token 时,允许代表最初经过身份验证的用户调用 User.Read。

在代表文档中,它声明了有关使用 /.default 范围的以下内容 -

/.default and combined consent

The middle tier application adds the client to the known client applications list in its manifest, and then the client can trigger a combined consent flow for both itself and the middle tier application. On the Microsoft identity platform endpoint, this is done using the /.default scope. When triggering a consent screen using known client applications and /.default, the consent screen will show permissions for both the client to the middle tier API, and also request whatever permissions are required by the middle-tier API. The user provides consent for both applications, and then the OBO flow works.

我已经尝试了应用程序注册中的各种配置组合以及范围请求的不同组合,但我根本无法使其按预期运行;该提示似乎不包含联契约(Contract)意。我让它发挥作用的唯一方法是手动向 User.Read 的后端应用程序提供管理员同意,这看起来像是一种黑客攻击,我更愿意正确配置它以请求用户同意。

如果有人之前配置过类似的东西(似乎是预期的用例),请告诉我你是如何让它工作的,包括类似的配置

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

在这个阶段,我将不得不恢复使用单一应用程序注册并在前端和后端之间共享相同的访问 token ,尽管就我个人而言,这对我来说似乎是一个较差的解决方案。

最佳答案

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

授权客户端应用程序出现在 UI 中,并且可以从“公开 API”区域进行配置 -

enter image description here

但是,这与已知客户端应用程序不同,后者是仅在编辑 list 时才能找到的设置 -

enter image description here

这个难题的关键部分是 -

  • 将您的前端应用客户端 ID 添加到后端应用注册 list 中的knownClientApplications
  • 使用前端应用登录时,您的范围需要为 {{api_clientid}}/.default,其中 {{api_clientid}} 是您的客户端 ID您的后端应用注册

这将在用户同意时向用户展示您在后端应用程序注册中配置的 API 权限,并且允许您的后端进程使用 OBO 流检索 AccessToken。

无论如何,这个教程帮助我意识到我需要更新 list ,并为我提供了有关确切的 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

关于使用单独的前端和后端应用程序进行 Azure AD 代表身份验证,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/64850790/

29 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com