Azure Active Directory Graph API (Windows Graph API) vs Microsoft Graph API

Working on a recent project I’ve decided to script the registration of Azure Applications, as I’m not dealing with one application, not five, not ten, but almost a dozen of Azure Applicatoins with almost the same configurations.

The obvious choice seems to be AzureAD poweshell module, easy to set-up, but this went quite ugly in the end, due to various endpoints are required for different configurations, so really I’ve been dealing with a mixture of Windows Graph API (via Azure AD powershell module), and Microsoft Graph API beta Microsoft Graph API v1 (raw http request).

Here is a quick summary I think would be useful to share:

  endpoint common used client Api (for pemissions) in Azure App Audience
Windows Graph Api https://graph.windows.net Azure AD powershell module/Azure Cli Azure Active Directory Graph https://graph.windows.net/
Microsoft Graph Api beta https://graph.microsoft.com/beta Microsoft.Graph powershell module Microsoft Graph https://graph.microsoft.com
Microsoft Graph Api v1.0 https://graph.microsoft.com/v1.0 Microsoft.Graph powershell module Microsoft Graph https://graph.microsoft.com

A few things may worth mentioning:

  • Azure AD Module allows you to connect as service principal, but only via certificate. The alternative is to get a client credential token yourself then use it to log in instead: $cred = Connect-AzureAD -TenantId $tenantId -AadAccessToken $byot -AccountId $spClientId

  • The actuall application/delegated permission needed are usually well documented, so if you are hitting an “insufficent privilege error” calling graph api, check the Permissions section of the API reference, e.g.: https://docs.microsoft.com/en-us/graph/api/serviceprincipal-post-serviceprincipals?view=graph-rest-1.0&tabs=http

  • While the client side tools (Az Cli, powershell modules, or Teraform) has provided an easy-to-use wrapper in front of the actual graph API, it is STILL important to understand which API you are calling into, so the correct application/delegated permissions are granted in your the service prinpal you are calling from, i.e.: “Azure Active Directory Graph” and “Microsoft Graph” are two DIFFERENT resources.

  • Do not fully rely on client side tools - there are always cases you’ll find a required feature not support by client side tools, so be prepared to fiddler around with API directly.

  • A useful link explains how to capture the traffic behind Azure Cli - Python lib under the hood doesn’t go through standard system proxy: https://samcogan.com/capturing-terraform-azure-cli-traffic-with-fiddler/

  • There are some validations on Windows Graph API side, e.g.:
    • cannot declare the delegated and application permission for the same resource.
    • cannot create a client secret for an application declared as public client.

    These however may NOT be a constraint on Microsoft Graph API - but tbc.

  • API reference:
    • Windows Graph API: https://docs.microsoft.com/en-us/previous-versions/azure/ad/graph/api/api-catalog
    • Microsoft Graph API: https://docs.microsoft.com/en-us/graph/api/overview?view=graph-rest-1.0

Retrospective:

If I ever had chance to do it again, not via raw request, then Microsoft.Graph powershell module will be a better option from now on. However it was still in pre-release status when I first look into this area, and the documentation is not as good as Azure AD module. However going forward it will be right tool to use as Microsoft has announced the deprecation of the Azure Active Directory Graph API (graph.windows.net) recently, some dates are mentioned below:

https://techcommunity.microsoft.com/t5/azure-active-directory-identity/update-your-applications-to-use-microsoft-authentication-library/ba-p/1257363

Written on September 16, 2020