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

Posted 2023-03-04

【中文标题】未返回带客户端凭据流的范围

【英文标题】：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？

【参考方案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