This blog post will cover how to use the graph API to access a user’s information stored in your Azure Active Directory(AAD) subscription. Accessing registered user information efficiently is a fundamental component of any business to consumer(B2C) web application; be it for simple display purposes or for giving the user freedom to change his/her info. Now we could use an SQL database to store each users’ information and then query it but that would be like using a cannon to kill a fly:
To better comply with DevOps best practices, we can harness the power of Microsoft’s dedicated APIs. Microsoft Graph API can be used to connect and manage the Office 365 SaaS platforms such as SharePoint Online, Office 365 Groups, OneDrive, OneNote, Azure AD, Teams (in beta) and more!
Key steps to achieve this are:
Before we dive into it, let’s briefly review the two types of APIs which Microsoft currently offers namely the Azure AD Graph API(graph.windows.net) and the Microsoft Graph API(graph.microsoft.com). In general, Microsoft recommends the use of the newly improved Microsoft Graph over Azure AD Graph, as Microsoft Graph is where most cloud service will be invested in the future. However, as of today, Microsoft Graph does not support management of B2C users while Azure AD does. Hence, while Microsoft is working hard to close the gap between Microsoft Graph and Azure AD Graph functionality, we will go ahead and use Azure AD for our example below. More information regarding these two can be found here: https://blogs.msdn.microsoft.com/aadgraphteam/2016/07/08/microsoft-graph-or-azure-ad-graph/
Setting applications permissions in Azure portal
First we will need to grant our application credentials to access the graph API.
Head over to the Azure portal (https://portal.azure.com) and choose Azure Active Directory in the left blade:
Click on App registrations and choose the registered application you want to grant access to:
Go to the Settings section of you registered app and choose Required Permissions under API Access:
Add the Windows Azure Active Directory API by clicking on the Add button and selecting the graph API. Note: If you would like to use the Microsoft Graph API then choose that instead. Click on Select once you are done selecting your API
Then we can grant our application whatever permissions we want by selecting from the list under Application Permissions.
Since we are only interested in manipulating AAD user data in this case, let’s give the application only Read and write directory data permission. Click save and then finally click on the Grant Permissions button:
Your application now has authorization to read and write a user’s data stored in AAD. Before we leave the portal, make sure to note down your Application ID and generate an Application Secret which can be done by going to the Keys section of your application settings. This will be necessary in the next section to make a secure call to the resource provider and request a token.
Acquiring a secure token via a suitable authentication flow
Let’s dive into some coding once we have our app infrastructure sorted out. Before we can access the graph API via our application, we need to acquire a secure token with which we can make an asynchronous request. I will be using the Client Credentials flow to acquire this token by using the latest version of Active Directory Authentication Library(ADAL). The flow is summarised as below:
The client ID/Secret to be sent to the Graph API are the application ID/Secret we noted down earlier. Making a request with these credentials returns our access token along with its scopes, expiry time etc. The resources we will be fetching with this token are the User details stored in AAD. The following code snippets implements this flow:
ADAL’s latest library conveniently allows us to form a ClientCredential element with the application ID and secret. We can then use it to asynchronously acquire a token by making a call to “https://login.microsoftonline.com/” + tenantID.
Let’s check if we are able to successfully acquire a token by setting a breakpoint:
The response is conveniently returned as a JSON object so we can extract the token by returning authResult.AccessToken. In ADAL’s latest libraries the token is automatically refreshed once it has expired which makes it that much simpler to use.
Using token to retrieve/modify the signed in user’s details
To finally access the graph API, we can use the ActiveDirectoryClient library to make another asynchronous request using the token we generated above. This will return a graphclient object:
Let’s return the current signed in user’s details which are also returned as a JSON object. Recall the permissions we have granted earlier via the Azure portal. Our application has rights to access user data stored in Active Directory. Of course we will want the signed in user to only see his/her personal information, so we will need to return a user by their unique ObjectId:
And it’s as simple as that folks!
You can use this JSON object however you want in your view to design your User Profile page.
We have seen how to grant permissions to our application registered in the Azure Active Directory to access the graph API, This allowed us to acquire a token in our .Net web application via the client credentials flow. There is also the more secure authorization code credential whereby we acquire a token by using an authentication code during sign in, but that is a topic to explore another time.
For more information on this service and more Devops practices check out Microsoft Graph blogs: https://blogs.technet.microsoft.com/sharepointdevelopersupport/tag/graph-api/ and of course our blogs at cubesys.