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

Question

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

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

应用程序开发人员基于角色的访问控制文档清楚地表明了谁管理访问：

...应用程序开发人员定义角色而不是授权单个用户或组。然后，管理员可以将角色分配给不同的用户和组，以控制谁有权访问内容和功能。

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

当我从另一个应用程序请求访问我的 API 时，情况如下所示：

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

“需要管理员同意”列显示组织的默认值。但是，可以根据权限、用户或应用程序自定义用户同意。此列可能无法反映您的组织或将使用此应用程序的组织中的价值。

也：

作为同意过程的一部分，当用户/管理员授予应用程序权限时，应用程序有权调用 API

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

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

Answer 1

我想在这里解释一下 Azure ad 提供的保护 Web api 的功能。

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

如果您有一个Web应用程序（例如Web mvc应用程序），您可以将Azure AD集成到其中，然后您可以允许用户使用他们的user1@xx.onmicrosoft.com帐户登录。如果您有一个Web api项目，您还可以集成Azure AD并在上面添加[Authorize]属性控制器，以便传入请求应包含正确的承载令牌，我们称之为访问令牌。

对于Azure AD，我们通常有2个选项，验证范围或应用程序角色。这是由于我们用于生成访问令牌的不同流程造成的。例如，我们使用身份验证代码流来登录用户并生成包含scp被授予delegatedapi 权限的声明的访问令牌。我们使用客户端凭证流让应用程序生成包含声明的访问roles令牌，该声明表示它已被授予applicationapi 权限。简而言之，当我们在控制器中设置[Authorize]+时，它允许来自用户的请求（用户登录应用程序并调用 api），当我们设置 时，它允许来自应用程序的请求（没有用户登录，应用程序自行调用 api） ）。 [RequiredScope(scopeRequiredByApi)][Authorize(Roles = "roleRequiredByApi")]

这里scopeRequiredByApi和roleRequiredByApi是您暴露然后添加到 的内容App Registration > Permissions。就像Integrator您在屏幕截图中标记的那样，它可以被识别为，roleRequiredByApi因为它的类型是 Application.

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