M365 Authentication, API Requests, and Blocked Endpoints

A recent customer support case required deeper insights into the API requests originating from WikiTraccs. A list of endpoints was required to whitelisting those at the proxy level.

While the WikiTraccs Endpoint Reference already covers endpoints, they weren’t detailed enough.

How to get more details?

I’ll describe how to use Microsoft’s Dev Proxy tool to get a list of endpoints.

Using Dev Proxy to Log API Requests

Dev Proxy is a small command line tool that creates a local proxy that can be used to log and change API requests of applications. It’s provided by Microsoft and free to use.

We’ll use Dev Proxy to log all API requests that WikiTraccs makes.

Once installed, we configure it. Configuration is done via a JSON file.

The following configuration instructs Dev Proxy to log all requests to the console:

{
    "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v0.24.0/rc.schema.json",
    "plugins": [
        {
            "name": "UrlDiscoveryPlugin",
            "enabled": true,
            "pluginPath": "~appFolder/plugins/dev-proxy-plugins.dll",
            "urlsToWatch": [
                "https://*/*"
            ]
        }
    ],
    "logLevel": "information",
    "newVersionNotification": "stable",
    "showSkipMessages": true,
    "showTimestamps": true
}

Save above text to devproxy.json.

Now we start Dev Proxy and instruct it to monitor WikiTraccs-related processes. Run the following command in a Terminal:

devproxy --config-file "C:\path\to\file\here\devproxy.json" --watch-process-names WikiTraccs.GUI WikiTraccs.Console conhost chromedriver chrome

Dev Proxy will now log all API requests done by WikiTraccs or the Chrome browser.

API Request for Authenticating with Microsoft 365

Since the customer that triggered this investigation reported problems when authenticating with Microsoft 365, let’s have a look at the API calls that go over the wire when doing that.

When hitting the Test SharePoint Connection button in the blue WikiTraccs.GUI window, the following endpoints are called:

1. https://login.microsoftonline.com/common/discovery/instance?api-version=1.1&authorization_endpoint=https://login.microsoftonline.com/421cd8a4-daf6-434c-8eae-a685c9af1808/oauth2/v2.0/authorize
2. https://login.microsoftonline.com/421cd8a4-daf6-434c-8eae-a685c9af1808/oauth2/v2.0/authorize?scope=https://contoso.sharepoint.com/.default+openid+profile+offline_access&response_type=code&client_id=b05e893b-866e-40d3-be10-75e44e5c38c2&redirect_uri=http://localhost:64189&client-request-id=bbc47ed0-c9e4-44e5-b1df-72c6589892e8&x-client-SKU=MSAL.NetCore&x-client-Ver=4.61.3.0&x-client-OS=Microsoft+Windows+10.0.22000&prompt=select_account&code_challenge=snip&code_challenge_method=S256&state=snip&client_info=1
3. https://login.microsoftonline.com/421cd8a4-daf6-434c-8eae-a685c9af1808/reprocess?ctx=snip&sessionid=a11f9fda-ae88-4a93-8d8b-68a3dd193e7b
4. https://login.microsoftonline.com/421cd8a4-daf6-434c-8eae-a685c9af1808/oauth2/v2.0/token
5. https://contoso.sharepoint.com/sites/testing/_api/Web?$select=Id,Url,RegionalSettings/*,RegionalSettings/DateFormat&$expand=RegionalSettings,RegionalSettings/TimeZone
6. … more calls of the SharePoint API

Note that

• 421cd8a4-daf6-434c-8eae-a685c9af1808 is the SharePoint tenant ID
• b05e893b-866e-40d3-be10-75e44e5c38c2 is Entra ID application client ID
• https://contoso.sharepoint.com is the SharePoint tenant URL

Unblocking above endpoints should make the authentication succeed.

Simulating Blocked Connections

Keep reading if you want to know how to simulate slow network connections or incomplete proxy configuration.

This is one of the value propositions of Dev Proxy: you can see how applications behave in unexpected circumstances.

I’d like to emulate a proxy that delays responses of certain endpoints related to Microsoft 365 authentication.

Let’s extend the configuration file for Dev Proxy as follows:

{
    "$schema": "https://raw.githubusercontent.com/dotnet/dev-proxy/main/schemas/v0.24.0/rc.schema.json",
    "plugins": [
        {
            "name": "UrlDiscoveryPlugin",
            "enabled": true,
            "pluginPath": "~appFolder/plugins/dev-proxy-plugins.dll",
            "urlsToWatch": [
                "https://*/*"
            ]
        },
        {
            "name": "LatencyPlugin",
            "enabled": true,
            "pluginPath": "~appFolder/plugins/dev-proxy-plugins.dll",
            "configSection": "latencyPlugin1",
            "urlsToWatch": [
                "https://login.microsoftonline.com/common/discovery/instance*"
            ]
        },
        {
            "name": "LatencyPlugin",
            "enabled": true,
            "pluginPath": "~appFolder/plugins/dev-proxy-plugins.dll",
            "configSection": "latencyPlugin2",
            "urlsToWatch": [
                "https://login.microsoftonline.com/421cd8a4-daf6-434c-8eae-a685c9af1808/oauth2/v2.0/token*"
            ]
        }
    ],
    "latencyPlugin1": {
        "minMs": 180000,
        "maxMs": 180000
    },
    "latencyPlugin2": {
        "minMs": 86400000,
        "maxMs": 86400000
    },
    "logLevel": "information",
    "newVersionNotification": "stable",
    "showSkipMessages": true,
    "showTimestamps": true
}

This configuration file adds the LatencyPlugin that slows down responses for endpoints. It is added two times, for two different endpoints, to set two different delays.

Endpoint one is https://login.microsoftonline.com/common/discovery/instance - this gets a response delay of 3 minutes (180000 ms).

Endpoint two is https://login.microsoftonline.com/421cd8a4-daf6-434c-8eae-a685c9af1808/oauth2/v2.0/token - this gets such a high response delay that it is equivalent with the proxy stalling forever.

Running Dev Proxy with above configuration has the following effects on WikiTraccs, both when testing the SharePoint connection and when starting a migration:

• the browser tab for logging in to SharePoint Online will only appear after a 3-minute delay
• after (seemingly) successful authenticating with SharePoint Online, WikiTraccs will wait for 100 seconds and run into a timeout, never completing the authentication

While waiting, WikiTraccs will appear stuck, not giving any feedback at all. This is something that needs to be addressed in a future update.

PnP.PowerShell

A quick aside about PnP.PowerShell which you might use in Microsoft 365-related projects.

Under the hood, WikiTraccs uses the same authentication mechanism as PnP.PowerShell.

This is why the Dev Proxy configuration from the last section will also make PnP.PowerShell fail when connecting.

Here’s the PnP.PowerShell command that corresponds to what WikiTraccs does when connecting to SharePoint Online:

Connect-PnPOnline -Url https://contoso.sharepoint.com/sites/testing -LaunchBrowser -ClientId b05e893b-866e-40d3-be10-75e44e5c38c2 -Interactive -Tenant 421cd8a4-daf6-434c-8eae-a685c9af1808

In this command:

• -Url https://contoso.sharepoint.com/sites/testing is the SharePoint site to connect to
• -LaunchBrowser tells it to open a tab in a browser where you can re-use an existing login
• -ClientId b05e893b-866e-40d3-be10-75e44e5c38c2 is the Entra ID application client ID; this can be the same you use for WikiTraccs
• -Interactive says that you’ll sign in with account credentials
• -Tenant 421cd8a4-daf6-434c-8eae-a685c9af1808 is the tenant ID to use; you can copy that from the blue WikiTraccs.GUI window

So, if you ever want to test how your PowerShell scripts behave in “special” circumstances - you now know how.

Wrap

In this post we looked at the API endpoints that WikiTraccs uses when logging in to Microsoft 365 and how to assemble this list using Microsoft’s Dev Proxy tool.

As an aside we also looked at how to use Dev Proxy to simulate “special” network conditions and hint at how to test PowerShell scripts under similar conditions.

• ←Previous
Next→