The "AAD Instance Discovery Endpoint" should be azureCloudInstance enum specific

[ashokdasari]

Core Library

MSAL.js v2 (@azure/msal-browser)

Core Library Version

2.22.1

Wrapper Library

MSAL Angular (@azure/msal-angular)

Wrapper Library Version

2.1.2

Description

The "AAD Instance Discovery Endpoint" is hardcoded to use "https://login.microsoftonline.com/common/discovery/instance?api-version=1.1&authorization_endpoint=" in the file "msal-common\src\utils\Constants.ts". It should be based on the environment/AzureCloudInstance specified by the config enum "AzureCloudInstance" in at the time of instantiating the object PublicClientApplication.
For example, If I specify the environment as AzureCloudInstance.AzureUsGovernment, then the endpoint should use "https://login.microsoftonline.us/common/discovery/instance?api-version=1.1&authorization_endpoint=" (.us instead of .com).

Or at least, there should be a way for client applications to override the "Default AAD Instance Discovery Endpoint".

This is a critical requirement for us as we allow only "https://login.microsoftonline.us" in our network and .com version is blocked.
Need this to be fixed as soon as possible.

Error Message

No response

Msal Logs

No response

MSAL Configuration

{
        auth: {
          clientId: environment.azureConfig.clientId, // This is your client ID
          authority: environment.azureConfig.authority, // This is your tenant ID
          redirectUri: environment.azureConfig.redirectUrl, // This is your redirect URI
          azureCloudOptions: {
            azureCloudInstance: AzureCloudInstance.AzureUsGovernment
          }
        },
        cache: {
          cacheLocation: 'localStorage',
          storeAuthStateInCookie: isIE, // Set to true for Internet Explorer 11
        },
}

Relevant Code Snippets

None

Reproduction Steps

Using the above configuration, at runtime, once we try to login to the AD, it is making a call to the "AAD Instance Discovery Endpoint" i.e., "https://login.microsoftonline.com/common/discovery/instance?api-version=1.1&authorization_endpoint=".
The URL login.microsoftonline.com is blocked for us in our network level as we only allow login.microsoftonline.us.
As we use AzureUsGovernment environment, it should use `login.microsoftonline.us' throughout the application.``

Expected Behavior

The library should use the AAD Instance Discovery Endpoint based on the AzureCloudInstance enum value passed in the configuration. or it should let the consumers override the default endpoint.

Identity Provider

Azure AD / MSA

Browsers Affected (Select all that apply)

Chrome, Firefox, Edge, Safari, Internet Explorer

Regression

No response

Source

External (Customer)

[ashokdasari]

Closing as we whitelisted the '.com' version of the URL in our network.

[alfred-stokespace]

This issue was not resolved.
I've also been trying to access https://login.microsoftonline.us/ and for me I must get tokens from this source as my tenant is not in the ...com system.

I used tcpdump -i any -c 10 (on wsl ubuntu 20.04) to prove that .us was not being hit...

13:56:17.558491 IP 172.26.54.105.41652 > DESKTOP-XXXXXX: 48688+ A? login.microsoftonline.com. (43)
13:56:17.558518 IP 172.26.54.105.41652 > DESKTOP-XXXXXX: 59454+ AAAA? login.microsoftonline.com. (43)

I read through the code of relevant repo https://github.com/AzureAD/microsoft-authentication-library-for-js
and found that if I turned on verbose logging I could see where the mixup was happening...

 const app = new ConfidentialClientApplication({

    system: {
      loggerOptions: {
        loggerCallback(loglevel, message, containsPii) {
          console.log(message);
        },
        piiLoggingEnabled: false,
        logLevel: LogLevel.Trace
      }
    },
    auth: {
... redacted ...

that allowed me to see that the metadata discovery for that URL was not being found until going down to the network (not sure what that means)

console.log
    [Tue, 06 Jun 2023 21:04:22 GMT] : [2f2dc1c7-320f-47c6-980b-9f2c7594aad4] : @azure/[email protected] : Verbose - buildOauthClientConfiguration called

      at Logger.log [as localCallback] (src/auth.ts:38:19)

  console.log
    [Tue, 06 Jun 2023 21:04:22 GMT] : [2f2dc1c7-320f-47c6-980b-9f2c7594aad4] : @azure/[email protected] : Verbose - building oauth client configuration w
ith the authority: https://login.microsoftonline.us/REDACTED

      at Logger.log [as localCallback] (src/auth.ts:38:19)

  console.log
    [Tue, 06 Jun 2023 21:04:22 GMT] : [2f2dc1c7-320f-47c6-980b-9f2c7594aad4] : @azure/[email protected] : Verbose - createAuthority called

      at Logger.log [as localCallback] (src/auth.ts:38:19)

  console.log
    [Tue, 06 Jun 2023 21:04:22 GMT] : @azure/[email protected] : Trace - Retrieving all cache keys

      at Logger.log [as localCallback] (src/auth.ts:38:19)

  console.log
    [Tue, 06 Jun 2023 21:04:22 GMT] : @azure/[email protected] : Trace - Getting cache key-value store

      at Logger.log [as localCallback] (src/auth.ts:38:19)

  console.log
    [Tue, 06 Jun 2023 21:04:22 GMT] : @azure/[email protected] : Verbose - Attempting to get cloud discovery metadata in the config

      at Logger.log [as localCallback] (src/auth.ts:38:19)

  console.log
    [Tue, 06 Jun 2023 21:04:22 GMT] : @azure/[email protected] : Verbose - Did not find cloud discovery metadata in the config... Attempting to get cloud
 discovery metadata from the cache.

      at Logger.log [as localCallback] (src/auth.ts:38:19)

  console.log
    [Tue, 06 Jun 2023 21:04:22 GMT] : @azure/[email protected] : Verbose - Did not find cloud discovery metadata in the cache... Attempting to get cloud
discovery metadata from the network.

      at Logger.log [as localCallback] (src/auth.ts:38:19)

  console.log
    [Tue, 06 Jun 2023 21:04:22 GMT] : @azure/[email protected] : Verbose - Attempting to find a match between the developer's authority and the CloudInstanceDiscoveryMetadata returned from the network request.

      at Logger.log [as localCallback] (src/auth.ts:38:19)

  console.log
    [Tue, 06 Jun 2023 21:04:22 GMT] : @azure/[email protected] : Verbose - cloud discovery metadata was successfully returned from getCloudDiscoveryMetadataFromNetwork()

but when I found this suggestion ( #4879 (comment) ) to set knownAuthorities to include the url I thought that might be a way to go...

and sure enough once I included it ...

auth: {
      knownAuthorities: [`https://login.microsoftonline.us/${options.tenantId}`],

I was able to confirm with that earlier tcpdump command that I was now in fact hitting .us

14:09:28.583715 IP 172.26.54.105.59908 > DESKTOP-XXXXXXXX: 28868+ A? login.microsoftonline.us. (42)
14:09:28.583746 IP 172.26.54.105.59908 > DESKTOP-XXXXXXXX: 45762+ AAAA? login.microsoftonline.us. (42)

Dependencies (msal-node was tried with both 1.17.2 and as shown 1.9.0, neither worked.)
and can confirm that http-proxy-agent and https-proxy-agent are both >= 5.0.0

"dependencies": {
    "@actions/core": "^1.7.0",
    "@azure/msal-node": "^1.9.0",
    "@microsoft/microsoft-graph-client": "^3.0.5",
    "@microsoft/microsoft-graph-types": "^2.19.0",
    "cross-fetch": "^3.1.5",
    "glob": "^8.0.1",
    "isomorphic-unfetch": "^4.0.2"
  },
  "devDependencies": {
    "@babel/preset-env": "^7.22.4",
    "@babel/preset-typescript": "^7.21.5",
    "@jest/globals": "^29.5.0",
    "@types/glob": "^7.2.0",
    "@types/mocha": "^10.0.1",
    "@typescript-eslint/eslint-plugin": "^5.21.0",
    "@typescript-eslint/parser": "^5.21.0",
    "@vercel/ncc": "^0.33.4",
    "eslint": "^8.14.0",
    "jest": "^29.5.0",
    "typescript": "^4.6.3"
  },