The reason why I decided to make this guide is that most of the time when I\u2019ve been looking up guidance or information on this topic, I end up finding a narrow example that doesn\u2019t help me understand all the options available. A common misconception I also hear is that people are just looking for how to pull an access token for Graph, but this is a bit too broad and has led me down a path of confusion in the past where I was trying methods that ultimately did not work. Understanding what methods are available to meet your needs will help you equip yourself to have an informed conversation with your Cloud\/Security teams to evaluate what makes the most sense for your own scenarios.<\/p>\n
I recognize that not all of us come from a development background, so this 3 part guide is going to help provide some tangible examples and guidance around what I think the hardest part about using the Graph API is, authentication. Each part will be broken down as follows:<\/p>\n
- \n
- \n
Part 1: Intro (Identifying the required permissions for your use case)<\/p>\n<\/li>\n
- \n
Part 2: Application Permissions<\/p>\n<\/li>\n
- \n
Part 3: Delegated Permissions<\/p>\n<\/li>\n<\/ul>\n
Typically, the process begins with the identification of what exactly you are trying to achieve and then finding the necessary permission scopes and type that are available. Understanding this is critical as there are 2 primary types of permissions: Delegated and Application<\/strong>. In either case, scripts can<\/em> run interactively or non-interactively. I will say though that it\u2019s generally easier, more secure, and less overhead to use application permissions<\/em> if your script needs to run non-interactively. Here\u2019s how I think of them:<\/p>\n
Note: Microsoft Documentation on this topic is available <\/em>here<\/em><\/a>.<\/em><\/p>\n
Application Permissions:<\/strong> The access token pulled performs actions without a user account.<\/p>\n
Delegated Permissions:<\/strong> The access token pulled performs actions on behalf of the user that is authenticated when requesting the token.<\/p>\n
The reason why this is so important to understand is that the methods that are available to authenticate can vary based on what types of permissions are required for the use case. You should never mix Application Permissions with Delegated Permissions.<\/strong><\/p>\n
Example:<\/strong> Let\u2019s say you want to create a script that can silently pull device data out of Intune and export it to a CSV on an automated schedule. Since we know we want our script to run non-interactively on a schedule, therefore if there are application permissions available, that would be the preferred option.<\/p>\n
Note: In some cases, Application or Delegated permissions might not be available, which may require some creativity to meet your needs.<\/em><\/p>\n
Follow these steps to find the necessary permissions for the use case at hand:<\/p>\n<\/div>\n\n\n\n
![\"\"](\"http:\/\/nkascocom.nk\/wordpress\/wp-content\/uploads\/2024\/03\/permissions.png\")
<\/figure>\n\n\n\n\n- \n
- \n
Head over to the Microsoft Graph REST API reference<\/a> page (Keep in mind there are 1.0 and beta versions available currently)<\/p>\n
- \n
- \n
I often find myself searching Google instead, in this case, I\u2019d search \u201cget device graph api\u201d which will lead you here: https:\/\/learn.microsoft.com\/en-us\/graph\/api\/device-get?view=graph-rest-1.0&tabs=http<\/a><\/p>\n<\/li>\n
- \n
Another option would be to use this cmdlet from the Microsoft.Graph<\/a> module<\/p>\n
Find-MgGraphPermission device<\/code><\/pre>\n<\/li>\n<\/ul>\n<\/li>\n- \n
We can see that in our example use case, there are permission sets available for both Application and Delegated to get device data. As mentioned above, our preference in this case would be to use Application.<\/p>\n<\/li>\n
- \n
The least privileged Application permission required for our use case is Device.Read.All<\/strong>.<\/p>\n
- \n
- \n
Keep this jotted down as it will be required later.<\/p>\n<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n
Microsoft Graph authentication is built upon the Microsoft Identity Platform for which the best way I\u2019ve found to authenticate is by using 1 of 2 available modules: MSAL.PS<\/strong><\/a> or Microsoft Graph PowerShell<\/strong><\/a>. However, ultimately the Microsoft Graph PowerShell module is suggested to use once a token has been retrieved as it cleanly handles passing the token in the request headers automatically, and there are many cmdlets available to simplify the process. With that said, it is not absolutely mandatory to use if you find a gap or cannot use it in your environment for whatever reason.<\/p>\n
Now that you\u2019ve identified what types of permissions are needed for your use case, click the corresponding link below for more information on next steps. This will help you understand what is required regarding the configuration of an Azure AD App Registration as well as how to actually make the proper authentication call from PowerShell:<\/p>\n<\/div>\n\n\n\n
- \n
- \n
- \n