Logging in with a live account fails when requesting consent with invalid_request: The provided request must include a 'client_id' input parameter.

Library

• msal@1.x.x or @azure/msal@1.x.x
• @azure/msal-browser@2.12.0
• @azure/msal-node@1.x.x
• @azure/msal-react@1.x.x
• @azure/msal-angular@0.x.x
• @azure/msal-angular@1.x.x
• @azure/msal-angular@2.0.0-beta.0
• @azure/msal-angularjs@1.x.x

Framework

• Angular@11.2.4
• React
• Other

Description

Trying to log in to an application fails when trying to ask for consent. Using more than the default scope profile or open_id produces an error as described below. Scopes on the application are Files.ReadWrite.All Sites.Read.All offline_access OpenId Profile User.Read and when I go to the URL

https://login.live.com/oauth20_authorize.srf?client_id={my client ID}&scope=Files.ReadWrite.All%20Sites.Read.All%20offline_access%20OpenId%20Profile%20User.Read&response_type=code&redirect_uri={my redirect URL}

as described at

https://docs.microsoft.com/en-us/onedrive/developer/rest-api/getting-started/msa-oauth?view=odsp-graph-online

I get a proper consent prompt but with msal-angular I get an error message:

Error Message

After login with a hotmail.com account, I get stranded on:

https://login.live.com/oauth20_authorize.srf?res=error&ec=&uaid={ some ID }

with a message:

invalid_request: The provided request must include a 'client_id' input parameter.

MSAL Configuration

export function MSALInstanceFactory(): IPublicClientApplication {
  return new PublicClientApplication({
    auth: {
      clientId: environment.msal.clientId,
      authority: environment.msal.authority, // = https://login.microsoftonline.com/common/
      redirectUri: environment.msal.redirectUri,
      navigateToLoginRequestUrl: true,
      knownAuthorities: [],
    },
    cache: {
      cacheLocation: BrowserCacheLocation.LocalStorage,
      storeAuthStateInCookie: isIE,
    },
    system: {
      loggerOptions: {
        loggerCallback,
        logLevel: LogLevel.Error,
        piiLoggingEnabled: false
      },
      tokenRenewalOffsetSeconds: 300,
      navigateFrameWait: 1000,
      windowHashTimeout: 60000,
      iframeHashTimeout: 6000,
      loadFrameTimeout: 0
    },
  });
}

Reproduction steps

I used the basic code from the sample at

https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/samples/msal-angular-v2-samples/angular11-sample-app

I changed the Client_ID to my own registered application which has two specific configuration changes. I removed the WEB as platform and added the Single-page Application reply url instead. I also changed the audience to:

"signInAudience": "AzureADandPersonalMicrosoftAccount",

Expected behavior

Able to sign in with both my AzureAD account as my Live.com account.

Identity Provider

• Azure AD
• Azure B2C Basic Policy
• Azure B2C Custom Policy
• ADFS
• Other

Browsers/Environment

• Chrome
• Firefox
• Edge
• Safari
• IE
• Other: Microsoft Edge Legacy (sideloading the page as an add-in through a manifest.xml in Office)

Regression

This failed in previous versions too but since this is a beta and still exists I’m trying to report the bug

• Did this behavior work before? Version:

Security

• Is this issue security related?

Source

• Internal (Microsoft)
• Customer request

[tnorling]

Capturing the token and adding it to graph calls yourself seems like a job for MSAL, not something you’d have to do yourself.

This sample just uses msal-browser by itself, which does not have an interceptor like msal-angular. In your case you should be able to use the msal-angular interceptor to do this.

Can you confirm that the auto navigated Post you mentioned is the point where msal makes the sideloaded Edge bug out and start an external instance with loss of context? Feels like something msal does makes this happen and could maybe be detected and fixed?

Our understanding when talking to the folks in office is that this was caused by a domain allow list in your manifest. One of the domains that was being navigated to was not explicitly allowed and the Office was redirecting the request to another API that can handle it. In this case, it’s ultimately not that important as sideloading Edge is not the correct way to handle auth in an office add-in.

[tnorling]

@brugh Yeah you’ll need to add a #code route to your routing module like demonstrated in the sample.

Closing but please feel free to open a new issue if you continue to have issues getting this set up. Thanks!