未返回带客户端凭据流的范围答案

【问题标题】：Scopes Not Returned w/ Client Credential Flow未返回带客户端凭据流的范围
【发布时间】：2020-03-01 05:10:26
【问题描述】：

在 Azure AD 中使用 client credential flow 时，我可以定义自定义范围并返回它们吗？

在我的实验中，我配置了 2 个 Azure AD 应用程序，一个用于 Web API，一个用于客户端（Web API 客户端 A）。我向 Web API 添加了一个范围，但是当通过 client credential flow 请求访问令牌时，没有返回范围。 ????

此外，它只允许我在将.default 用于范围时请求访问令牌，即api://web-api-client-credential-flow/.default。

我遇到了这个 Azure 反馈项：V2.0 Client Credentials Implement Scopes，所以在客户端凭据流下，Azure AD 似乎不支持范围？

如果我的 Web API 客户端 A 应用程序没有返回该范围的权限，有什么意义？ Web API 如何知道守护程序应用程序是否具有执行必要操作的范围？

看来我必须使用application permissions？

【问题讨论】：

标签： oauth-2.0 azure-active-directory

【解决方案1】：

是的，您需要使用api://web-api-client-credential-flow/.default 进行客户端凭据流。

并且应用程序权限将在角色而不是作用域中返回。

【讨论】：

【解决方案2】：

是的，您必须使用应用程序权限。

范围又名委派权限仅在用户参与登录过程时适用。它们允许您代表用户行事。

应用程序权限是赋予应用程序本身的某种角色。它们仅适用于不涉及用户的客户端凭据身份验证。您可以通过应用程序注册中的清单定义应用程序的应用程序权限。然后可以将这些分配给客户端应用程序。获取令牌时，您必须使用 .default ，因为您无法动态更改应用权限。你总是得到已经被授予的东西。在令牌中，权限将在角色声明中。

【讨论】：

似乎是 Azure AD 的一个缺点?。 MSFT Graph has delegated and app scopes。想知道RFC 是否讨论过这个？
我觉得其他 IdP 对它的定义有点不同，因为他们也使用服务范围来服务。这是他们很久以前做出的设计决定：\ 现在很难在不破坏所有应用程序的情况下进行更改。
总是添加“更好”的方式，而放弃旧的方式?
Okta 允许 custom scopes 使用客户端凭据流?

【解决方案3】：

在 Azure AD 中使用客户端凭据流时，我可以定义自定义范围并返回它们吗？

不，但您可以定义application permission(s) via the manifest（绝对不如委托范围的 UI）并通过客户端凭据流返回它们：

然后你可以提供客户端应用权限：

现在，当请求范围为api://web-api-client-credential-flow/.default 的令牌时，“范围”将在roles 声明中返回。 Sample JWT

【讨论】：