使用客户端凭据流以编程方式在 Azure AD 中添加应用程序

Posted 2023-03-04

【中文标题】使用客户端凭据流以编程方式在 Azure AD 中添加应用程序

【英文标题】：Adding Applications programmatically in Azure AD using Client Credentials Flow

【发布时间】：2016-04-18 04:54:50

【问题描述】：

为了与 Azure API 管理一起使用，我尝试以编程方式将 应用程序 添加到 Azure Active Directory (AAD)，在我的例子中是使用 Graph API。

我的场景如下：为了保护我想使用 Azure API 管理管理的 Web API，我想利用 AAD 的 OAuth 功能来完成有关身份验证和颁发 JWT 令牌的繁重工作，然后只使用验证-jwt 策略来验证 Azure API 管理中的一切是否正常。这样做的好处是我可以或多或少地在后端服务中省略身份验证。

只要我在 Azure AD 中为使用 Web 应用程序创建了一个应用程序，就可以正常工作，但这必须从 Azure 门户手动完成； Azure APIm 不会自动执行此操作。

现在我要尝试自动完成：我想将 APIm 中的 API 订阅委托给我正在编写的其他一些 Web 应用程序，然后我想利用 Graph API 创建一个应用程序在 Azure AD 中并向 API 的应用程序授予权限。

我尝试做的第一件事是让第三个应用程序（我的服务应用程序）对 Azure AD 中的 Windows Azure Active Directory 应用程序拥有完整的应用程序权限；这让我的应用程序可以使用 Graph REST API 访问 AAD。我设法使用 client_credentials 授权（来自 login.microsoft.com）获得访问令牌，但这个令牌不允许我在 https://graph.windows.net/(my AAD ID)/applications?api-version=1.5 上执行 POST：

    
        "odata.error": 
            "code": "Authorization_RequestDenied",
            "message": 
                "lang": "en",
                "value": "Insufficient privileges to complete the operation."
            
        
    

我发现 (https://msdn.microsoft.com/Library/Azure/Ad/Graph/howto/azure-ad-graph-api-permission-scopes) 即使我授予Directory.ReadWrite.All 权限，应用程序（仅限应用程序）将无法创建或更新应用程序：

注意：特别不包括上面未列出的实体的创建或更新。 这包括：应用程序、Oauth2PermissionGrant、AppRoleAssignment、设备、 ServicePrincipal、TenantDetail、域等

接下来我尝试的是资源所有者密码授权 (grant_type=password)，另外传递我自己的凭据，以便我可以在 Graph API 中模拟自己。现在，我的POST 到applications 端点成功了。

我的底线问题是：我能否向我的应用程序授予足够的权限，以便我可以使用客户端凭据流而不是代表用户的任何流以编程方式添加应用程序？如果是这样，它是如何完成的？

【问题讨论】：

我发现了另一个讨论，很可能归结为与我遇到的完全相同的问题：social.technet.microsoft.com/Forums/en-US/… 此外，我还找到了讨论 Graph API 权限的页面：msdn.microsoft.com/Library/Azure/Ad/Graph/howto/…

他们为您的问题提供解决方案吗？

不，很遗憾没有。冒充管理员是我目前发现的唯一“解决方案”。

【参考方案1】：

对不起，唐。我们目前没有任何可用于创建应用程序或服务主体或创建任何 oauth2 权限授予（或您通过目录在上面提到的任何其他实体）的客户端凭据流（仅限应用程序）的权限范围。 ReadWrite.All 权限）。我们正在开发额外的仅限应用程序权限，让您能够点亮此场景，但我没有可以给您的 ETA。

如果您使用应用程序+用户（代码流）并授予应用程序 Directory.AccessAsUser.All 权限，则此操作应该是可能的 - 只要有用户使用您的应用程序并且他们是租户管理员。不确定这是否是您可以接受的解决方法（我猜这与您在密码流中使用的类似 - 尽管我建议您在此处使用代码流）。

更新：我们为 AAD Graph 添加了一些仅限应用的新权限。 Application.ReadWrite.OwnedBy（它允许一个应用程序创建/拥有另一个应用程序 - 但只更新它创建的应用程序 - 它无法触及它不拥有的任何其他应用程序）和 Application.ReadWrite.All （其中允许应用程序创建/管理租户中的所有应用程序）。好像第一个比较合适。您可以在 AAD Graph resource 的 Azure 门户中看到这些显示。

【讨论】：

是的，这将是一种可接受的解决方法。同时，我们还提出了以下想法（未验证），方向相同，但不需要具有 API 使用者角色的用户成为 AD 管理员：我们可以“启动”控制网络应用程序使用 AD 管理员的凭据授予授权码（这样我们就不必将它们存储在应用程序中），然后刷新应用程序中的令牌以将该管理员的模拟保留在应用程序内，而无需手动干预。但这也给人一种不好的感觉。

没有。它没有。资源所有者密码授予确实如此。

一旦我们获得必要的应用程序权限，我将更新此线程。一旦我们有了它，这个流程将适用于客户端凭据流程。唐，您所做的将起作用（缓存刷新令牌），但您需要确保它被安全存储 - 加上该令牌最终会过期（通过最后一次使用或管理员的密码过期），需要您的管理员同意再次。当我们拥有应用程序权限时，客户端凭据听起来像是要走的路。

@DanKershaw-MSFT：我知道你说过你会关注这个帖子，但是你有什么更新吗？

抱歉回复晚了。刚刚添加了对答案的更新。