azure - 无需用户交互即可检索 OAuth 2.0 授权代码

Question

我正在尝试使用 Microsoft Flow 创建工作流程。我的一些步骤是使用 Microsoft Graph API 执行 HTTP 请求。我遇到的问题是某些 API 不支持应用程序权限类型，而是支持委托(delegate)类型。我正在尝试在 Microsoft Planner ( see this link ) 中创建计划。在此场景中，我创建了将执行特定工作流的服务帐户，并且在 Azure AD 应用程序端，我以管理员身份代表用户授予了权限。

因为我必须以“用户”身份执行某些 HTTP 请求，所以我尝试检索用户授权 token ，这里有两个步骤:

1. 检索授权码
2. 根据授权码检索Token

我无法通过第 1 步。我正在遵循此文档:https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow每次我尝试执行以下 HTTP 请求时:

GET https://login.microsoftonline.com/{my-tenant-id}/oauth2/v2.0/authorize?
client_id={my-client-id}
&response_type=code
&redirect_uri=https%3A%2F%2Flogin.microsoftonline.com%2Fcommon%2Foauth2%2Fnativeclient
&response_mode=query
&scope=Group.ReadWrite.All

我通过传递用户名和密码来使用基本身份验证。但我收到的回复是“我们无法让您登录，您的浏览器当前设置为阻止 cookie”。好吧，没有浏览器，它是服务帐户。我是否遗漏了某些东西，或者我想要实现的目标是不可能的，并且我必须拥有网络应用程序？ Microsoft 制作了使用 Planner API 的连接器，但他们制作了除了连接器之外的所有内容，以便在 Planner 中制定计划...

编辑:

我知道问题类似 to this topic here ，但本主题中的答案说要使用“应用程序授权”，微软在其文档中特别指出，在这种情况下您不能。我知道我需要实际的用户权限，因为唯一允许的权限类型是

Delegated (work or school account)

这就是为什么特定主题无法回答我的问题，因为该答案指出了此场景中不支持的应用程序权限。

Answer 1

我认为您遇到了问题，因为授权代码授予流程旨在与用户交互配合使用，即用户被重定向到登录页面以交互方式输入凭据。您可以在相关的 SO 帖子 OAuth2 - Authorize with no user interaction 中阅读更多相关信息。 (它不是特定于 Azure AD 的，而是关于一般的 OAuth 2.0 授权代码授予流程。

替代方案

1. Client Credentials Grant Flow

对于任何后台/守护进程来说，这都是理想的和最佳的选择，但它将与应用程序权限一起使用。不幸的是，您尝试使用的 API 仅适用于您提到的委派权限，因此此授予不起作用。

Resource Owner Password Grant Flow (这可行，但违反了安全最佳实践并且存在功能问题)

ROPC 直接使用用户凭据(即您的代码可以直接访问用户名和密码，这无论如何都不是一个好的做法)，并且不需要显式交互。尽管这可能有效，但请注意，此授权违反了许多安全最佳实践，并且它也有功能限制(例如不适用于多重身份验证或个人帐户)。

查看此相关SO Post我已经更详细地介绍了这些内容。通常我不会提及这项资助，但我没有看到任何其他资助对您的案例起作用，这是包含它的唯一原因。

示例请求

     // Line breaks and spaces are for legibility only.

     POST {tenant}/oauth2/v2.0/token
     Host: login.microsoftonline.com
     Content-Type: application/x-www-form-urlencoded

     client_id=6731de76-14a6-49ae-97bc-6eba6914391e
     &scope=user.read%20openid%20profile%20offline_access
     &<a href="https://stackoverflow.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="b8cdcbddcad6d9d5dd85f5c1edcbddcad6d9d5ddf8d5c1ecddd6d9d6cc96dbd7d5" rel="noreferrer noopener nofollow">[email protected]</a>
     &password=SuperS3cret
     &grant_type=password

Using Refresh Token (可以工作，但它也很脆弱，更像是一种解决方法)

在这种方法中，您可以首先使用服务帐户获取刷新 token 。您需要将其与应用程序的一般工作分开来执行，例如作为初始设置和用户交互的一部分。

然后您可以根据此刷新 token 获取 token 。刷新 token 可能会被撤销或过期。因此，您需要了解刷新 token 的有效时间以及刷新 token 可能失效的事件。密码更改等事件也可能使现有刷新 token 无效。此外，您还需要像敏感信息一样保护刷新 token (几乎就像密码本身)

所以据我所知，我只是建议几个不好的选项，即 2 和 3。不幸的是，API 不支持应用程序权限，因此淘汰了这个好的选项。