I recently needed to fetch all users contained within a Microsoft Azure Active Directory tenant from within a trusted application running on a Windows 10 computer.

For this, I implemented a .NET Console Core console application that utilizes the Microsoft Graph API to fetch the needed data.

Microsoft provides NuGet packages that makes this a breeze. Assuming the application has been registered in Azure Active Directory and a Client Secret has been created, access can be obtained by constructing an IConfidentialClientApplication object using ConfidentialClientApplicationBuilder like so:

IConfidentialClientApplication confidentialClientApplication = ConfidentialClientApplicationBuilder
   .Create(clientId)
   .WithTenantId(tenantId)
   .WithClientSecret(secret)
   .Build();

Where clientId is the Guid of the application, tenantId is the Guid of the Azure Active Directory Tenant and secret is the client secret. The IConfidentialClientApplication and ConfidentialClientApplicationBuilder types are exposed the Microsoft.Identity.Client NuGet package.

To Access the Graph API, a GraphServiceClient must be constructed. This object provides properties and methods that can chained to construct queries towards the API.
This type is provided by the Microsoft.Graph NuGet Package.

GraphServiceClient needs an instance of a IAuthenticationProvider for it to be able to get an access token.
Microsoft provides ClientCredentialProvider which takes our IConfidentialClientApplication as parameter. ClientCredentialProvider is provided by the Microsoft.Graph.Auth NuGet package.

IAuthenticationProvider authProvider = new ClientCredentialProvider(confidentialClientApplication);

Note: The Microsoft.Graph.Auth package is currently in preview. Make sure to check “Include prerelease” to be able to find this package if you use the NuGet Package Manager in VS2019

Since ClientCredentialProvider implements the IAuthenticationProvider interface, we can now instantiate the GraphServiceClient

GraphServiceClient graphClient = new GraphServiceClient(authProvider);

With this, we can do queries towards the graph API. The following example gets all users of the Active Directory and returns these as an IGraphServiceUsersCollectionPage for further processing.

IGraphServiceUsersCollectionPage users = await graphClient.Users
   .Request()
   .Select(e => new {
      e.DisplayName,
      e.GivenName,
      e.PostalCode,
      e.Mail,
      e.Id
})
.GetAsync();

That’s it! Remember to provide the needed API Permissions for the application if you intent to execute the query above:

The .NET framework has been branched into several implementations to match the constraints of the target platforms, e.g. Compact Framework for Pocket PC, Mono for Linux and the full .NET Framework for Windows.

This poses a problem regarding library compatibility between them. Writing a library is not straightforward since one has to target the specific framework in which the library is consumed.  This has somewhat been alleviated by Portable Class Libraries (PCLs), since this type of library can target multiple frameworks. It is not a 100% solution, since when a new framework emerges the library in question is not automatically compatible with the new framework.

The solution has been to introduce a versioned formal API specification called .NET Standard. This standard is implemented by all the most common framework implementations. Writing a library targeting .NET Standard 1.0 ensures that the library can be consumed across different frameworks, if they implement the .NET Standard 1.0.

The .NET Framework 4.5 implements .NET standard 1.1 while .NET Framework 4.6 implements .NET Standard 1.4. Writing a library for both .NET Framework 4.5 and 4.6 can easily be done by targeting .NET Standard 1.1. Also, Windows Phone 8.1 and Mono implements .NET Standard 1.3 or above making the said library compatible with these implementations.

Each new version of the .NET Standard inherits from the previous version, making a new version a super-set of the old version. The API specification is written i C#, making it straight forward to read and adapt the API to a new implementation.

.NET Core is the latest framework implementing .NET Standard, more on this later.

Nearly all my latest projects have some sort of RESTful API. For testing purposes I use Postman, a HTTP client aimed at making it easier to test APIs by allowing custom messages to be formed.

The application can be run as a Chrome app or downloaded for Windows, MacOS and Linux distros as an application (executable).

Testing GET using the browser is straightforward, unless some specific header needs to be constructed. Testing POST, PUT, etc. is typically harder in a browser, since the browsers addressline is tied to GET (for obvious reasons).

Postman allows one to use many (if not all) of the HTTP methods. Postman allows one to specify the body of e.g. a POST. It allows also the ability to specific the exact headers for the request.

Frequently used requests can be saved into a history which is searchable, and one can also make collections of HTTP requests for specific applications.

Regarding the body content, postman supports TEXT, JSON, HTML, XML, etc. Binary is also supported by choosing a file on the disk to send.

Highly recommended for those who build or consume RESTful APIs.