I have not touched Microsoft Graph in quite some time, and a recent project has forced me to re-familiarize myself with accessing it. It seems like things are always changing — whether it’s Microsoft changing Azure to Entra or npm packages being deprecated. I need to re-learn this stuff if I’m not keeping up with the ecosystems. I found myself looking for the best way to authenticate in order to use Microsoft Graph, and it seems that the Microsoft Authentication Library (MSAL) is the way to go.
I came across a nice article describing the “Microsoft identity platform”: “The Microsoft identity platform is a cloud identity service that allows you to build applications your users and customers can sign in to using their Microsoft identities or social accounts. It authorizes access to your own APIs or Microsoft APIs like Microsoft Graph.”
Since my use case involves developing a Node.js application, I found that the Microsoft Authentication Library for Node (msal-node) was exactly what I needed. “It also enables your app to get tokens to access Microsoft Cloud services such as Microsoft Graph.”
I had a moment of pause when I read through the README.md, particularly with all of the mentions of “Azure AD.” However, after exploring the GitHub repository’s roadmap, active issues, pull requests, and recent commits, I concluded that this must be an oversight in the documentation. I decided that this package is safe to use and will be supported for the foreseeable future.
A working example
I came across this tutorial on calling the Microsoft Graph API in a Node.js console daemon app and got it running pretty quickly. Be mindful that this example reflects what I imagine writing a Node.js CLI tool is like.
The flow
I quickly realized that using the Microsoft Graph API boils down to two ideas:
- You use msal-node to authenticate with Entra ID and establish a session.
- Using the above session, you communicate with Microsoft Graph via one of the two methods highlighted below.
- I’m sure there are more than these two ways, but here is what I found worked for me.
Communicating with Microsoft Graph
I found two ways to interact with Microsoft Graph. Each has its pros and cons, and I advise you to test what works best for you based on your use case.
Option 1: Using @microsoft/microsoft-graph-client
The @microsoft/microsoft-graph-client package is a client library that simplifies interaction with the Microsoft Graph API. It abstracts away many of the complexities of direct API calls, such as token management, header setup, pagination, and query construction. The client library integrates seamlessly with MSAL for token handling and provides chainable methods for making API requests, resulting in cleaner and more maintainable code. This approach also offers built-in error handling, automatic paging, and full TypeScript support, making it ideal for scenarios where you need to interact with multiple Graph API endpoints or handle larger data sets efficiently.
Option 2: Direct API Calls to Microsoft Graph API
Communicate directly with the Microsoft Graph API using HTTP requests. You’ll need to handle tasks such as obtaining and managing access tokens (using a library like msal-node), setting up request headers, constructing the API endpoint URLs, and managing pagination for larger data sets manually. While this method provides full control over the API interactions, it requires more boilerplate code and is more prone to errors, especially when dealing with token management and response handling. Direct API calls can be useful for simple, lightweight operations, but become cumbersome for more complex workflows.
Summary
Essentially, you need two things:
- To authenticate
- To query the Microsoft Graph API
Collecting all of this information took some time and was scattered across the various articles I linked above. Having said that, I hope this summary saves you some time and helps you better understand what is required to get answers from Microsoft Graph.