【问题标题】:Accessing Graph API's through delegated permissions of service account without user interaction通过服务帐户的委托权限访问 Graph API,无需用户交互
【发布时间】:2019-03-28 03:25:52
【问题描述】:

我正在寻找允许应用通过服务帐户访问 Graph API 的最佳方法。

这个想法是为该应用授予 Graph API 的委派权限,然后通过该应用中使用的服务帐户的访问权限进一步限制该权限。问题是服务帐户不需要交互。

例如:我希望开发人员创建任何类型的应用程序来访问 Graph API,但只管理他的服务帐户被授予访问权限的资源。例如,我不希望他能够管理所有 AAD 组,而只希望他的服务帐户拥有所有权的 AAD 组。

有什么指导可以让我开始演示吗?我一直在寻找教程和文章,但似乎没有一个符合我的要求。

【问题讨论】:

    标签: azure azure-active-directory


    【解决方案1】:

    目前我认为您无法做到这一点。 如果您进行客户端凭据身份验证(客户端 ID + 机密/证书), 应用程序权限适用。 委派权限仅在涉及用户时适用。 因此,目前限制范围的唯一方法是代表用户进行调用。

    当然,您仍然可以将其大部分自动化。 一种方法是让开发人员使用他们的帐户进行一次身份验证。 然后,您的应用应该会收到该用户的刷新令牌, 然后它可以根据需要使用它来获取新的访问令牌,以便随时以用户身份进行调用。

    当然,刷新令牌的唯一问题是它们可能会过时或被撤销。 开发人员必须再次授权该应用程序。 如果不发生这种情况是关键业务, 那么您必须使用应用权限(组织范围、所有组等)。

    【讨论】:

    • 嗨@juunas,这是有道理的。但是在实践中你会怎么看呢?您会推荐哪种 OAuth 流程?目标当然是构建关键业务应用程序,因此确实可以避免无法再请求新访问令牌的刷新令牌。可以采取哪些措施来避免刷新令牌无法请求新的访问令牌?
    • 如果我没记错的话,密码重置是使该用户的所有刷新令牌无效的事情之一。
    • 另外,我建议每天使用刷新令牌,并用返回的新刷新令牌替换旧刷新令牌。这使它不会过时。
    • 谢谢,我会看看如何以编程方式解决这个问题。关于 OAuth 2.0 流程:如果我的用户通过 WS-Federation (SSO) 进行身份验证,这是否会阻止我使用 v2 端点,因为它不支持 WS-Federation 或者仅适用于应用程序?
    • 嗯,我不确定。您的意思是他们通过 WS-Fed 向其他应用程序进行身份验证?在这种情况下,它没有任何区别。每个应用程序都可以选择他们想要使用的协议和端点。
    【解决方案2】:

    您可能想看看Get access without a user

    某些应用使用自己的身份调用 Microsoft Graph,而不是在 代表用户。在许多情况下,这些是后台服务或 在没有登录用户的情况下在服务器上运行的守护进程。

    ...

    认证授权步骤

    配置服务和获取令牌所需的基本步骤 服务可用于调用 Microsoft 的 Azure AD v2.0 终结点 图下自己的身份是:

    1. 注册您的应用。
    2. 在您的应用上配置 Microsoft Graph 的权限。
    3. 征得管理员同意。
    4. 获取访问令牌。
    5. 使用访问令牌调用 Microsoft Graph。

    关键是权限的配置。可能需要深入研究permissions reference 以查看它是否提供了您需要的粒度。

    2。为 Microsoft Graph 配置权限

    对于以自己的身份调用 Microsoft Graph 的应用,Microsoft Graph 公开应用程序权限。 ...您预先配置 注册应用时您的应用所需的应用权限。

    【讨论】:

    • 嗨@'James Wood',这对我来说已经或多或少清楚了。问题是我们不想分发应用程序权限,因为它们没有范围。开发人员必须确保范围以编程方式完成,我们必须信任...
    猜你喜欢
    • 2020-09-23
    • 2015-02-12
    • 1970-01-01
    • 1970-01-01
    • 2020-08-04
    • 2021-09-05
    • 1970-01-01
    • 1970-01-01
    • 2017-03-15
    相关资源
    最近更新 更多