Introduction

This blog post is to help users stand up an Azure Active Directory Application Registration, explain what permissions will be needed to added to the AAD Application Registration, how to make rest calls to get an access token, and then finally call the Microsoft Graph API to do whatever call you would like to do.

 

Please note, that not all permissions are going to be within Azure. i.e. If you are making a Microsoft Graph call to Outlook and would like access to a calendar using a delegated permission, and the user making the call doesn’t have access to said calendar, the call still will not work as the user does not have access to the calendar.

 

Also Please note that there are two different versions of the Graph API, the Azure Active Directory Graph API and the Microsoft Graph API.

In addition to that, note that the Microsoft Graph API has two endpoints right now, the beta endpoint and the V1 endpoint, do not confuse this with the v1 and v2 endpoints for Azure portal as the azure v1 and v2 endpoints are not related to the Microsoft Graph’s v1 and beta endpoints.

 

Setting Up the AAD Application

The first step to getting access to the Microsoft Graph REST API is to setup an AAD Application Registration.

First we are going to want to create the AAD Application registrations in the portal. For this we will need to configure the application to be able to work with Postman so that we can make the call to the Microsoft Graph API. First we go to the Azure Active Directory Blade, go to App Registrations, and then create a new application registration.

2018-03-31 19_16_00-Create - Microsoft Azure - Internet Explorer

From there we are going to want to create a web app with any name. Here I have set the name as web app, and set the Sign-On URL as the callback for Postman: https://www.getpostman.com/oauth2/callback, it is unimportant what the callback url is, but for our case we are using that callback URL for consistency sake. Just make sure that the callback you put down for your AAD Application Registration is the same in your postman call. This is unimportant for the grant type client credentials but more important for other grant type flows.

image

You will have to click out of the sign-on URL to make it check whether or not if it’s correct.

After that we have created our web app, we will want to create a secret. Please keep track of the secret as you won’t be able to see the secret again. You will have to press save in order for the secret to generate.

 

image

With this information in hand, we will be able to move forward and connect to this AAD registration. But without the correct permissions we won’t be able to get an access token to make calls to the Microsoft Graph API.

 

Finding Which Permissions We Need for a Microsoft Graph Call

Assuming we would like to have granular control on what the AAD Application registration has access to and what it doesn’t have access to. We are going to want to make sure that the AAD Application registration only has the permissions it needs to make the MSFT Graph API calls that we are wanting to make.

There has been a separate blog post on finding the correct permissions for your graph API call listed below :

Finding the Correct Permissions for a Microsoft or Azure Active Directory Graph Call

 

For this client credentials flow, we will want to set the required permission for Read all users’ full profiles under Application Permissions. If you check the delegated permission you won’t get the correct permissions because the client credentials flow only gets the application permissions. This permission is shown below.

 

image

 

 

Accessing the AAD App Registration and Calling the Microsoft Graph API

 

Now lets get a secret for our AAD Application registration by going to the keys blade and adding a secret. Please make sure to keep track of this key as you will not be able to retrieve it again once you leave the blade.

 

image

 

Be sure to press the save button in order to see the value after putting in the description for your key.

 

Now our AAD Application registration is ready to go and we can utilize postman to get an access token using the AAD Application registration to use the list users functionality in the Microsoft Graph API.

 

Please keep track of the client id as well which is the application id for your app registration. This is shown below.

image

 

We are going to want to get our token and authorize endpoints, we can find this next to the new application registration button in the App Registrations blade shown in the picture below.

 

image

 

Now we can go to our postman to try to get an Access token. Below is a screenshot of how the postman should be setup with the variables we got from the steps above.

 

We will use the token endpoint as the URL to post, we will then add the client id, client secret, resource, and grant type in the body of x-www-form-urlencoded fields.

 

The only item that isn’t gotten in the steps above is the resource which is different depending on what you’re trying to access. Here we are trying to access the Microsoft Graph which is https://graph.microsoft.com you will need to look through your respective documentation to find what the resource url is for the resource you’re trying to utilize if it’s not the Microsoft Graph.

 

image

 

After this we have now received an Access token back from the token endpoint for your Azure Active Directory tenant. With this access token we can create a new request with a single authorization header and the list user calls to the Microsoft Graph API.

 

image

 

We to have a header with the value as “Bearer <access token>” with the key “Authorization”.

 

image

 

We have now gotten the list of users from the tenant that the AAD Application Registration.

 

 

Conclusion

After going through the steps to create an AAD Application registration, finding what call we want to make, finding what permissions we need to make the call and then getting all the configurations we need to get an access token from the token endpoint. We were able to get an access token from the token endpoint and then make a call to the Microsoft Graph API with our access token to list the users in our tenant. I hope that you can utilize this flow to make the other calls to the Microsoft Graph API. If you have any issues feel free to open a support ticket and one of our support engineers will reach out to you as soon as possible, please be sure to have a fiddler trace of the error that you are experiencing.

8 Thoughts to “Using Postman to Call the Microsoft Graph API Using Client Credentials”

  1. Arun Manjila Purushothaman

    Hi, Thanks for the great post.
    I was able to get through all these steps successfully and got until /me or /users working.
    But how to get the calendar working with the same access? How do we map from Azure so that the User1’s events are accessible?

  2. Frank Hu MSFT

    Hello, I’m following up on this : “how to get the calendar working with the same access? How do we map from Azure so that the User1’s events are accessible?”
    That requires you to put the correct permissions on the AAD Application. For more information on that please go through this document : https://blogs.msdn.microsoft.com/aaddevsup/2018/05/21/finding-the-correct-permissions-for-a-microsoft-or-azure-active-directory-graph-call/

    That being said, the calendar is in Outlook, which requires different permissions as, there are two layers of security. AAD’s authentication, but then you have to make sure your account has the proper permissions on the outlook side to look at the calendar otherwise you will receive an access denied error.

    As the client credential flow only allows application permissions, you might not be able to access the calendar as it may require delegated permissions on behalf of the outlook user.Please file a support ticket with O365 Developer for further help on this issue.

    1. Frank Hu MSFT

      Sure, so that means that you have all the right permissions on AAD side, but you will need someone with Outlook expertise to get it working properly. Again, I suggest to create a support ticket with outlook to continue debugging this issue as this will require some more digging to get this working properly.

      1. Arun Manjila Purushothaman

        The issue was resolved when I used the O365 business account with Azure delegated permissions.
        The same settings were failing over outlook.com even though it was working from graph api, only failing was authentication issue between postman and outlook, couldn’t resolve that part.

        Thank you for all you great blogs, which really gives clarity and confidence to approach, keep sharing.

        1. Frank Hu MSFT

          Great! I’m glad that you were able to resolve the issue. I appreciate your feedback, and thanks for reading the blog.

  3. Hi Frank

    Thanks for the informative and useful article. Hopefully you an help me – I am unable to upload a file using a valid access token (the token allows me to list groups, drive items etc.). The error that appears is:

    “invalidRequest: One of the provided arguments is not acceptable.”
    Using the following PUT request:
    https://graph.microsoft.com/v1.0/groups/{my group id}/drive/items/{my item(folder) id}:/test.txt:/content
    using content type: text/plain

    I tested this exact same request using the graph explorer https://developer.microsoft.com/en-us/graph/graph-explorer and my office 365 user account and the upload worked, so I though it might be an app permissions thing, however this did not work even after granting absolutely every permission to the app and regenerating the access token.

    Hopefully you can help as I would rather use an access token in my app than my user account to perform the uploads.

    1. Frank Hu MSFT

      Hey Oliver,
      I see you’re trying to use the OneDrive API documented here : https://developer.microsoft.com/en-us/graph/docs/api-reference/v1.0/api/driveitem_put_content

      It looks like from what you’re saying in the comment, it should work properly using Postman as well, however it isn’t.

      It looks like this would require further inspection with the OneDrive Support team. I would suggest filing a support ticket with the O365 Developer Support team, and to provide them with a fiddler trace of a repro of the issue. This process is documented here : https://blogs.msdn.microsoft.com/aaddevsup/2018/09/12/capture-https-traffic-with-http-fiddler/

Leave a Reply to Arun Manjila Purushothaman Cancel reply