Custom Connector with Graph API using APPLICATION permissions. Is this even possible?

[MartinHatch]

I've been grappling with this for several days now. I have successfully created a PowerApps custom connector. 

I've tried doing Azure Active Directory and Generic OAuth 2 but both of them end up with the same result. 

When I try to "test" my endpoints every single request is submitted to Graph "on behalf of the user" as a Delegated API Permissions call.  I need to use Application permissions (i.e. it doesn't matter if the user has access or not). 

How exactly can I achieve this? 

The standard behaviour seems to *always* default to requests on behalf of the user. If I try to access an API endpoint where I only have Application assigned permissions, it doesn't work (Access Denied).

I get the feeling I might be able to do something with the Policy section, or editing in Swagger, but I don't really know what would need to be changed (or to what). 

Is this even possible? Is Power Apps effectively exclusively "on behalf of the current user"? 

[MartinHatch]

Note - I have interrogated the Swagger editor and it seems that the access flow defaults to "accessCode" 

This is basically "in the context of the current user" otherwise known as "User Context Flow" 

The intellisense in the Swagger editor DOES allow me to change this to "Application", but that runs into the problem that the Custom Connector doesn't provide anywhere to specify a Refresh URL or method through which you can either set or update the initial access token itself. 

This leads me to believe that Power Apps - Custom Connectors, in it's current state, does NOT support Application Context Flow (i.e. "Application permissions") and will ONLY allow you to execute "User Context Flow" OAuth2 requests

In Graph API terminology - you can only use delegated permissions. 

[cchannon]

5 months later, I am coming to the same conclusion, which makes me very sad.

@HemantG  - Where do we go for feature requests and suggestions WRT the custom connectors? They are a great concept, but this inability to use App Permissions and the forced use of static URLs are both killers to an enormous set of use cases.

[HemantG]

@SameerCh should be able to help you. 

hemant 

[cchannon]

Thanks - I already want to take back the static URL thing. Not sure when you added that one, but the {item} in pathing is a HUGE advance. Great work!

But back to what @MartinHatch found here: the inability to use app permissions to call anything with custom connectors is a big surprise. I mean, we can always work around by creating a service account 'user' but we have app registrations as service principals for a reason; they have different credential expiration rules and can use certificates we can lock away in a keyvault to "set it and forget it". By locking us to a specific user account -- namely, one that must be a username and pass and the Flow designer needs to have access to -- we're missing out on a very stable and useful auth pattern, even if it is the less common of the two.

[DanielPuckett]

I ask in advance for your forgiveness for any butchery I do to the terms and concepts here.

I have run into this as well on a small 'toy' project.  I was on a Zoom call and someone in the org called me on teams.  I thought.. I need to sync my Zoom and Teams presence.

Done, was easy enough, although I used a bit of a convoluted way to do it.  AND it revealed a problem opportunity challenge with delegated vs application permissions.

1. I have a Zoom Marketplace app (just a short mouse click config) that calls an Azure Function Webhook on change of presence.  
2. That Azure Function wraps the request body in JSON and calls a Power Automate Webhook Flow - I needed to do it that way as direct calls from Zoom to the Flow webhook would not work due to the authentication model presented by Zoom.  When in doubt, convert everything to a string and carry on.
3. That Power Automate Flow incorporates a Custom Connector for setting and clearing presence.  
4. The Custom Connector uses an Azure App Registration for authentication and provides for (among other permissions)

• Delegated Presence.ReadWrite
• Application Presence.ReadWrite.All

And it works. Wonderfully.  The Zoom presence when on a call gets 'stacked' on my other presence(s) and when cleared, my other presence in the 'stack' takes effect.    

i.e. Calendar says I'm Busy, take a Zoom call, now in a call, clear it, and still busy from my calendar.  Exactly as it should.

But this works only for my own presence.

Uses (Presence.ReadWrite).

But never satisfied.. I should make this available to others in the org, have then set their Zoom to call my Azure Function webhook and I'll take care of the rest.  But the Graph setPresence and clearPresence permission of Presence.ReadWrite.All ONLY exists as an Application permission.

Your post was reassuring in that it confirmed that my inability to figure out how to run my Custom Connector as an application at least put me into a similar league as people that are way more knowledgable about this stuff than I am.

Have you been able to find a workaround for your Custom Connector?

[RicoVT98]

@MartinHatch 

I have come across the same finding and no matter what I change in the Swagger Editor for the Flow Type, it always defaults back to accessCode.

Do you know if there's currently work in progress by Microsoft to support other flow type in the future?

[DanielPuckett]

Hi Rico, I should have come back to this thread and updated my findings.  No, not going to happen as a custom connector, but there was a simpler way around it.

My custom connector is simply a wrapper for some Graph calls using rights as configured in an Azure App Registration.  So..

Armed with my App Registration's Tenant ID, ApplicationID, and Secret that I was using in my custom connector, I use a HTTP object to get an authorization token and then use that token in subsequent Graph API calls using another instance of the HTTP object.

As follows:

Here is the Body and Schema:

tenant=@{variables('TenantID')}&client_id=@{variables('ApplicationID')}&client_secret=@{variables('Secret')}&grant_type=client_credentials&scope=<SCOPE removed by editor, oh well>

{

"type": "object",

"properties": {

"token_type": {

"type": "string"

},

"expires_in": {

"type": "integer"

},

"ext_expires_in": {

"type": "integer"

},

"access_token": {

"type": "string"

}

}

}

Then to use to make a Graph API call:

Hope that helps with your pursuits.

Daniel