Tech Community Live: Microsoft Intune
Jun 22 2023, 07:30 AM - 11:30 AM (PDT)
Microsoft Tech Community

Intune Graph API permissions - no Application permissions - why?

Regular Contributor

I'm hoping to gain an understanding why all Intune Graph resources and actions only allow Delegated permissions.  This essentially means no unattended administration available, at least not App-only.


I can't figure out why it is like this.  The Intune PowerShell SDK (i.e. Microsoft.Graph.Intune PowerShell gallery module) can be used unattended'ly, but the sample for this that is on GitHub is using ConvertFrom-SecureString | Out-File.  That's not really secure, nor is sending plain text password to MS Graph (not referring to the sample with the latter comment, rather this:  So Application permissions, enabling Certificate (or Client Credential) authentication would be far superior.


Referenced sample script:


Use cases that I'm particularly talking about are ones like resetPasscode, or remoteLock.  We should be able to trigger these actions with an App Registration that has Application permissions.  We could then script automatic reactions, such as remoteLock upon a particular Azure AD Sign-In event or risk detection.


Can somebody please tell me why Intune's Graph permissions are strictly only Delegated?  This same issue applies to about every single thing an Admin might want to use MS Graph API's for.  I wish there was a TON of focus in this area by Microsoft.  If magically all of a sudden customer administrative automation was catered to, this would be a massive positive thing leading to mass embracement from customers.  Right now, it sometimes seems like MS doesn't want customers automating things with unattended intention.


Thanks in advance.

7 Replies
best response confirmed by Jeremy Bradshaw (Regular Contributor)
Application support for all Intune endpoints have been added, but it's still in the beta Graph though

@Thijs Lecomte Thanks for the info, this is great.


I wonder how/when this will factor into the Intune PowerShell SDK.  I suppose they Connect-MSGraph cmdlet from the module/SDK will just need to get some client credential flow functionality added.

I wouldn't get your hopes up that the Powershell cmdlets will support application permissions

The Graph API is rather easy to use and I would recommend looking into this.
As the Graph API has support for features much earlier than the Powershell SDK
Good advice and duly noted. I've got a mini module ready to go for easy app-only certificate authentication to Graph so good there. Incidentally, I tested the beta remoteLock, and it seems to not work. Will need to test a bit I guess, or wait if it is truly just not working yet.
Know that beta channel contain some bugs, but it should a a minimum
Let me know if it doesn't work, I'll try to test as well

@Thijs Lecomte Thanks very much for this. - that is my module.  It currently is setup to accommodate certificate authentication in the client credential flow.  The functions are: 







For my example which is was failing, I'm I was getting an access token successfully, and then with New-MSGraphQuery can could successfully list devices using v1.0 or beta:



# list devices via v1.0:
>$q1 = New-MSGraphQuery -AccessToken $Token -API v1.0 -Method GET -Query deviceManagement/managedDevices
>$q1.value | select deviceName, model

deviceName                         model
----------                         -----
HTPC-G1                            Z390 I AORUS PRO WIFI
j_AndroidForWork_6/9/2020_10:12 PM ONEPLUS A5010

# list devices via beta:
>$q2 = New-MSGraphQuery -AccessToken $Token -API beta -Method GET -Query deviceManagement/managedDevices
>$Q2.value | select deviceName, model

deviceName                         model
----------                         -----
HTPC-G1                            Z390 I AORUS PRO WIFI
j_AndroidForWork_6/9/2020_10:12 PM ONEPLUS A5010

# fail to remoteLock via Beta:
>New-MSGraphQuery -AccessToken $Token -API beta -Method POST -Query deviceManagement/managedDevices/9e250f72-a995-401d-8e32-7edf7fdb2eba/remoteLock
Invoke-RestMethod : {
  "error": {
    "code": "No method match route template",
    "message": "No OData route exists that match template ~/singleton/navigation/key/action with http verb GET for request
    "innerError": {
      "request-id": "01f99d16-88e2-4b2c-b053-0fbfaec43947",
      "date": "2020-06-11T12:39:08"
At C:\Users\<myProfile>\GitHub\PowerShell\.Modules\msGraphFunctions.psm1:125 char:5
+     Invoke-RestMethod @QueryProps -OutVariable QueryResponse
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-RestMethod], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeRestMethodCommand



Upon crafting this reply, I noticed in the error "No OData route exists ....... with http verb GET for request".  This made me realize my problem.  I had hard-coded "Get" as the method in my New-MSGraphQuery function, where I should have set it to my parameter -Method's value ($Method).


Original, non-working code:


    $QueryProps = @{

        Headers     = @{ Authorization = "Bearer $($AccessToken.access_token)" }
        Uri         = "$($API)/$($Query)"
        Method      = 'Get'
        ContentType = 'application/json'



Fixed, working code:


    $QueryProps = @{

        Headers     = @{ Authorization = "Bearer $($AccessToken.access_token)" }
        Uri         = "$($API)/$($Query)"
        Method      = $Method
        ContentType = 'application/json'



Again, thanks very much!  I still needed this post and your response to get me looking at the Beta reference instead of v1.0.  It was only after that, that I could flush out this error in my script.  The -Method parameter was added to the function after a while, and I must have gotten distracted in the process and forgot to actually incorporate the parameter into the script after declaring in my params block.  All good now though!



Glad that worked!
Have fun automating Intune :)