Retrieve OAuth 2.0 authorization code without user interaction

Question

I am trying to create workflow using Microsoft Flow. Some of my steps are executing HTTP Requests using Microsoft Graph API. Problem I am encountering is that some API do not support Application Permission type, but rather Delegated. I am attempting to Create plan in Microsoft Planner (see this link). In this scenario I have created service account that will execute specific workflow and on the Azure AD application side I have granted permissions on behalf of user as administrator.

Because I have to execute certain HTTP Requests as "user" I am attempting to retrieve user authorization token there are two steps here:

1. Retrieve Authorization code
2. Retrieve Token based on authorization code

I cannot pass Step 1. I am following this documentation: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow and every time I attempt to execute following HTTP request:

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

I am using basic authentication by passing username and password. But I am getting response that "We can't sign you in, your browser is currently set to block cookies". Well there is no browser it is service account. Am I missing something or what I am trying to achieve is not possible and I have to have web application? Microsoft made connectors that use Planner API, but they made everything but connector to make plan in planner...

EDIT:

I am aware that issue is similar to this topic here, but answer in this topic says to use "App authorization" which is specifically pointed out by Microsoft in their documentation that in this scenario you cannot. I am aware of that I need actual user permissions as only type of permission allowed is

Delegated (work or school account)

this is why particular topic does not answer my question since that answer is pointing out to Application permission that is not supported in this scenario.

Answer 1

I think you're running into an issue because Authorization code grant flow is meant to work with user interaction, i.e. user gets redirected to login page to enter credentials interactively. You can read more about it in this related SO Post OAuth2 - Authorize with no user interaction (it's not specific to Azure AD but about OAuth 2.0 Authorization Code Grant flow in general.

Alternatives

1. Client Credentials Grant Flow

This would have been ideal and the best choice for any background/daemon process, but it will work with application permissions. Unfortunately the API you're trying to use only works with Delegated permissions as you have mentioned, so this grant won't work.

2. Resource Owner Password Grant Flow (this could work but violates security best practices and has functional issues)

ROPC works directly with user credentials (i.e. your code has direct access to username as well as password, which isn't a good practice by any means), and it doesn't require explicit interaction. Even though this could work out, please know that this grant violates many security best practices and it has functional limitations too (like doesn't work with Multi Factor Authentication, or with Personal accounts).

See this related SO Post where I have covered these in a little more detail. Normally I would refrain from mentioning this grant, but I don't see any other grant working in your case and that's the only reason to include it.

Sample request

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

3. Using Refresh Token (could work but it's also fragile and more like a workaround)

In this approach you could acquire a refresh token using service account first. You will need to do this separate from general working of the application, say as part of initial setup and with user interaction.

Then going ahead you can acquire token based on this refresh token. Refresh tokens can get revoked or expire. So you need to be aware of how long is refresh token valid for and events where it could become invalid. An event like password change could also make existing refresh token invalid. Also, you will need to secure the refresh tokens like a sensitive information (almost like a password itself)

So AFAIK, I'm only suggesting a couple of bad options, i.e. 2 and 3. Unfortunately API not supporting Application permissions takes out the good option.