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.

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

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.

tnorling on Apr 14, 2021