Question

我正在尝试使用Microsoft Flow创建工作流。我的一些步骤是使用Microsoft Graph API执行HTTP请求。我遇到的问题是某些API不支持Application Permission类型，而是Delegated。我正在尝试在Microsoft Planner（see this link）中创建计划。在这种情况下，我创建了将执行特定工作流的服务帐户，并且在Azure AD应用程序端，我已代表用户以管理员身份授予权限。

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

获取授权码
根据授权码检索令牌

我无法通过步骤1。我正在遵循此文档：https://docs.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”。好吧，没有浏览器，它是服务帐户。我是否缺少某些东西，或者我想实现的目标是不可能的，而我必须拥有Web应用程序？微软制造了使用Planner API的连接器，但是除了连接器之外，他们还制作了其他所有东西来在Planner中制定计划。

编辑：

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

委派的（工作或学校帐户）

这就是为什么特定主题无法回答我的问题的原因，因为该答案指出了这种情况下不支持的应用程序许可。

Answer 1

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

替代

Client Credentials Grant Flow

对于任何后台/守护进程来说，这都是理想的选择和最佳选择，但是它将在应用程序许可下起作用。不幸的是，您尝试使用的API仅与您提到的具有Delegated权限一起使用，因此此授予将无效。
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
 &username=MyUsername@myTenant.com
 &password=SuperS3cret
 &grant_type=password
```
Using Refresh Token（可以工作，但也很脆弱，更像是一种解决方法）

通过这种方法，您可以首先使用服务帐户获取刷新令牌。您需要将其与应用程序的常规工作分开进行，例如，作为初始设置的一部分并与用户交互。

然后，您可以基于此刷新令牌获取令牌。刷新令牌可能会被吊销或过期。因此，您需要了解刷新令牌的有效期限以及可能变为无效的事件。诸如更改密码之类的事件也可能使现有的刷新令牌无效。另外，您将需要保护刷新令牌（例如敏感信息）（几乎就像密码本身一样）

所以AFAIK，我只建议几个不好的选择，即2和3。不幸的是，不支持应用程序权限的API排除了很好的选择。

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

1 个答案: