在没有用户交互的情况下检索OAuth 2.0授权代码

Question

我正在尝试使用Microsoft创建工作流。我的一些步骤是使用Microsoft执行HTTP请求。我遇到的问题是某些API不支持应用程序权限类型，而是支持委托。我正试图在Microsoft (请参阅此链接)中创建计划。在这个场景中，我创建了将执行特定工作流的服务帐户，在Azure AD应用程序端，我代表作为管理员的用户授予了权限。

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

1. 检索授权码
2. 基于授权代码检索令牌

我无法通过步骤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”。没有浏览器，这是服务帐户。我是不是错过了什么，或者我想要达到的目标是不可能的，我必须有网络应用程序？微软制造了使用Planner的连接器，但是他们制造了除了连接器之外的所有东西来在计划器中制定计划。

编辑：

我知道问题类似于在这里讨论这个话题，但是在这个主题中的答案是使用“应用程序授权”，这是微软在他们的文档中特别指出的，在这个场景中你不能。我知道我需要实际的用户权限，因为只有允许的权限类型是

转授(工作或学校帐户)

这就是为什么特定的主题没有回答我的问题，因为这个答案指向在这个场景中不支持的应用程序权限。

Answer 1

我认为您遇到了一个问题，因为授权代码授予流用于使用用户交互，即用户被重定向到登录页面以交互方式输入凭据。您可以在这个相关的文章中了解更多关于它的内容，所以Post OAuth2 -没有用户交互的授权 (它不是专门针对Azure的，而是关于OAuth 2.0授权代码授予流的一般内容)。

替代品

1. 客户凭据授予流

这对于任何后台/守护进程来说都是理想的，也是最好的选择，但它将与应用程序权限一起工作。不幸的是，您试图使用的API只适用于您刚才提到的委托权限，因此此授权将无法工作。

1. 资源所有者密码授予流 (这可能有效，但违反了安全最佳实践，并且存在功能问题)

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

请参阅与此相关的所以波斯特，其中我已经详细介绍了这些内容。通常情况下，我会不提这笔赠款，但我认为在你的情况下没有任何其他的补助，这是唯一的理由包括它。

样本请求

     // 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

1. 使用刷新令牌 (可以工作，但它也很脆弱，更像是一个解决方案)

在这种方法中，您可以首先使用服务帐户获取刷新令牌。您将需要独立于应用程序的一般工作，例如作为初始设置的一部分和用户交互。

然后，您可以在此刷新令牌的基础上获取令牌。刷新令牌可能会被撤销或过期。因此，您需要知道刷新令牌在多长时间内是有效的，哪些事件可能会变得无效。像密码更改这样的事件也会使现有的刷新令牌无效。此外，您还需要像保护敏感信息一样保护刷新令牌(几乎就像密码本身一样)。

因此，AFAIK，我只是提出了一些不好的选项，即2和3。不幸的是，API不支持应用程序权限删除了好的选项。