gpt4 book ai didi

azure - Azure AD 应用程序注册中应用程序角色和范围之间的差异

转载 作者:行者123 更新时间:2023-12-02 05:59:08 31 4
gpt4 key购买 nike

我使用 Azure 中的应用注册创建了一个受 OAuth 保护的 API。我的应用程序注册不需要分配,但它公开了底层 API 验证的许多角色。据我了解,这几乎完成了与需要批准相同的事情。

到目前为止,我只有用户/组角色,但现在我添加了一个供集成商使用的应用程序角色,并且我希望其他应用程序所有者能够请求对我的 API 的权限。作为 API 所有者,我希望查看这些内容并拒绝或同意该请求。例如。我不希望每个人都能够在我不知情的情况下访问租户内的我的 API,就像所有用户/组在我将其分配给角色后都无权访问一样。

Role-based access control for application developers文档非常清楚谁管理访问:

...an application developer defines roles rather than authorizing individual users or groups. An administrator can then assign roles to different users and groups to control who has access to content and functionality.

但是,如果您创建一个角色并将允许的成员类型设置为应用程序,那么事情就不太清楚,并且它的行为似乎更像是一个范围,我放弃了任何访问管理。另外,根据我有限的理解,当 API 需要向用户请求数据(例如想要读取他们的用户名)时,会使用范围,而角色则用于应用程序开发人员控制对其正在开发的内容的访问。

当我请求从另一个应用程序访问我的 API 时,情况如下: enter image description here

同一页面提到了以下信息:

The "Admin consent required" column shows the default value for an organization. However, user consent can be customized per permission, user, or app. This column may not reflect the value in your organization, or in organizations where this app will be used.

以及:

Applications are authorized to call APIs when they are granted permissions by users/admins as part of the consent process

但是,从我的阅读来看,作为 API 所有者,这似乎从未让我深入了解谁有权访问我拥有的 API。我想要控制应用程序访问,就像在企业应用程序中为组或用户分配角色一样。

当另一端是应用程序而不是用户时,可以实现这一点吗?如果不是,我如何允许应用程序以受控方式集成?

最佳答案

我想解释一下 Azure ad 提供给 protect web api 的功能在这里。

如您所知,我们通常在请求 header 中使用 token 来让 api 检查请求是否具有访问 api 的正确权限。例如,如果请求来自允许的用户角色,对吧?所以整个过程应该是身份验证和授权。用户首先登录,然后尝试生成访问 token 来访问 api。 Azure AD 具有类似的架构。

如果您有一个 Web 应用程序(例如 Web mvc 应用程序),您可以将 Azure AD 集成到其中,然后您可以允许用户使用他们的 <a href="https://stackoverflow.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="6c191f091e5d2c141442030201050f1e031f030a18420f0301" rel="noreferrer noopener nofollow">[email protected]</a>如果您有 Web api 项目,还可以集成 Azure ad 并添加 [Authorize] Controller 上方的属性,以便传入请求应包含正确的承载 token ,我们称之为 access token .

对于 Azure AD,我们通常有 2 个选项,verification scopes or app roles 。这是由于我们用于生成访问 token 的不同流程造成的。例如,我们使用auth code flow登录用户并生成包含 scp 的访问 token 已批准的 claim delegated API 权限。我们使用 client credential flow让应用程序生成包含 roles 的访问 token 代表它被授予的声明 application API 权限。 简而言之,当我们设置[Authorize]时+ [RequiredScope(scopeRequiredByApi)]在 Controller 中,当我们设置 [Authorize(Roles = "roleRequiredByApi")] 时,它允许来自用户的请求(用户登录应用程序并调用 api)。 ,它允许来自应用程序的请求(没有用户登录,应用程序自行调用api)。

这里scopeRequiredByApiroleRequiredByApi是您暴露然后添加到 App Registration > Permissions 的内容。就像 Integrator你在截图中标注的,可以识别为roleRequiredByApi因为它的类型是Application .

恐怕roles不是您想要的,但说实话,我所说的是 AAD 可以为您做的事情...而且我认为我上面提到的有关验证范围或应用程序角色的文档将是您的一个很好的示例。

关于azure - Azure AD 应用程序注册中应用程序角色和范围之间的差异,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/74125779/

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