microsoft-authentication-library-for-js: Logging in with a live account fails when requesting consent with invalid_request: The provided request must include a 'client_id' input parameter.


  • 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


  • Angular@11.2.4
  • React
  • Other


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{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

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

Error Message

After login with a account, I get stranded on:{ 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, // =
      redirectUri: environment.msal.redirectUri,
      navigateToLoginRequestUrl: true,
      knownAuthorities: [],
    cache: {
      cacheLocation: BrowserCacheLocation.LocalStorage,
      storeAuthStateInCookie: isIE,
    system: {
      loggerOptions: {
        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

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 account.

Identity Provider

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


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


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:


  • Is this issue security related?


  • Internal (Microsoft)
  • Customer request

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 15 (1 by maintainers)

Most upvoted comments

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.