Closed grosch-intl closed 5 months ago
I have the same problem, it works flawlesley on Edge, but broken on chrome, here are my important bits
Sorry, but we’re having trouble signing you in.
AADSTS900144: The request body must contain the following parameter: 'client_id'.
/*! @azure/msal-browser v3.0.0-alpha.2 2023-05-22 */
// Config object to be passed to Msal on creation
const msalConfig = {
auth: {
clientId: "<client id>",
authority: "https://login.microsoftonline.com/<hidden tenant>",
},
cache: {
cacheLocation: "sessionStorage", // This configures where your cache will be stored
storeAuthStateInCookie: false, // Set this to "true" if you are having issues on IE11 or Edge
},
system: {
loggerOptions: {
logLevel: msal.LogLevel.Trace,
loggerCallback: (level, message, containsPii) => {
if (containsPii) {
return;
}
switch (level) {
case msal.LogLevel.Error:
console.error(message);
return;
case msal.LogLevel.Info:
console.info(message);
return;
case msal.LogLevel.Verbose:
console.debug(message);
return;
case msal.LogLevel.Warning:
console.warn(message);
return;
default:
console.log(message);
return;
}
},
},
},
telemetry: {
application: {
appName: "MSAL Browser V2 Default Sample",
appVersion: "1.0.0",
},
},
};
// Add here scopes for id token to be used at MS Identity Platform endpoints.
const loginRequest = {
scopes: ["<hidden scope>"]
};
const logoutRequest = {}
const myMSALObj = new msal.PublicClientApplication(msalConfig);
myMSALObj.initialize().then(() => {
// Redirect: once login is successful and redirects with tokens, call Graph API
myMSALObj.handleRedirectPromise().then(handleResponse).catch(err => {
console.error(err);
});
signIn('redirect');
});
async function signIn(method) {
console.log("Will redirect!");
signInType = method;
if (signInType === "popup") {
return myMSALObj.loginPopup({
...loginRequest,
redirectUri: "/redirect"
}).then(handleResponse).catch(function (error) {
console.log(error);
});
} else if (signInType === "redirect") {
return myMSALObj.loginRedirect(loginRequest);
}
}
function handleResponse(resp) {
console.log(resp);
if (resp !== null) {
accountId = resp.account.homeAccountId;
myMSALObj.setActiveAccount(resp.account);
handleTokenAnswer(resp);
} else {
// need to call getAccount here?
const currentAccounts = myMSALObj.getAllAccounts();
if (!currentAccounts || currentAccounts.length < 1) {
return;
} else if (currentAccounts.length > 1) {
// Add choose account code here
} else if (currentAccounts.length === 1) {
const activeAccount = currentAccounts[0];
myMSALObj.setActiveAccount(activeAccount);
accountId = activeAccount.homeAccountId;
console.log("Active account", activeAccount);
myMSALObj.acquireTokenSilent(loginRequest).then(handleTokenAnswer).catch(error => {
console.log(error);
});
}
}
}
I've been having the same issue - however, appears to be random. I'm not sure what triggers it.
MSAL opens the following link when attempting to login.
https://login.microsoftonline.com/TENANT_ID/oauth2/v2.0/authorize? client_id=CLIENT_ID_HERE& scope=SCOPES_HERE& redirect_uri=http://localhost:4200& client-request-id=CLIENT_REQUEST_ID& response_mode=fragment& response_type=code& x-client-SKU=msal.js.browser& x-client-VER=3.0.0-beta.0& client_info=1& code_challenge=CODE_CHALLENGE& code_challenge_method=S256& login_hint=MY_EMAIL_HERE& X-AnchorMailbox=XXXXXXXX& nonce=XXXXXXXX& state=XXXXXXXX& nativebroker=1& sso_nonce=XXXXXXXX& mscrid=CLIENT_REQUEST_ID
This link clearly contains a client_id
.
Down below you can see how the initilization is created.
constructor(
private authService: MsalService,
private msalBroadcastService: MsalBroadcastService,
) {}
ngOnInit() {
this.msalBroadcastService.inProgress$
.pipe(
filter((status: InteractionStatus) => status === InteractionStatus.None),
take(1)
)
.subscribe(() => {
this.checkAndSetActiveAccount();
});
}
checkAndSetActiveAccount() {
let accounts = this.authService.instance.getAllAccounts();
if (accounts.length > 0) {
var arr = environment.msalConfig.auth.authority.split('/');
var tenantId = arr[arr.length - 1];
const account = accounts.find((x) => x.tenantId == tenantId);
this.authService.instance.setActiveAccount(account );
this.loggedIn = true;
}
// Initiate login-flow and redirect to prev url if it exists;
else {
window.sessionStorage.setItem(AppComponent.REDIRECT_KEY, window.location.href);
// Make sure the user is prompted to select account instead of defaulting to the first account
const request = DEFAULT_REQUEST;
request.prompt = 'select_account';
this.authService.loginRedirect(request);
}
const redirectUrl = window.sessionStorage.getItem(AppComponent.REDIRECT_KEY);
if (this.loggedIn && redirectUrl) {
window.sessionStorage.removeItem(AppComponent.REDIRECT_KEY);
this.router.navigateByUrl(redirectUrl.replace(environment.msalConfig.auth.redirectUri, ''));
}
}
@grosch-intl @kaangoksal @Drsela Are you using the Windows Account extension to get tokens? Is this extension installed in Chrome and not in Edge?
There is a known bug on the server side related to the extension. This is being handled by another team and we do not currently have an ETA on the fix. You can try mitigating this by turning off the native broker in the configurations:
{
auth: {...},
cache: {...},
system: {
allowNativeBroker: false, // Disables WAM Broker
}
}
Please note that turning off the native broker is a temporary solution until the server bug is fixed.
@jo-arroyo yes, we are using this in a tenant that needs windows login, I have the chrome extension.
@jo-arroyo I'm not sure about the extension. I don't personally remember installing one, but it would depend on the customers using the website. Your allowNativeBroker
workaround seems to have fixed my problem though, thanks!
@jo-arroyo I spoke too soon. When deployed to the IIS server the allowNativeBroker
doesn't seem to make a difference. It's just when running locally from my host that it works.
@grosch-intl Our setup is similar to yours. We also use IIS to host our application. However, I don't believe that the issue is related to IIS.
@jo-arroyo I can confirm that I use a Windows Account. All of our users also use the extension, and it cannot be disabled (except in Incognito mode).
I tried setting allowNativeBroker to false, but it resulted in another error when trying to log in: "AADSTS70018: Invalid verification code."
Upon checking my Sign-In Activity via the Azure Portal, I observed the following error description for the login:
Field | Description |
---|---|
Authentication requirement | Single-factor authentication |
Status | Failure |
Continuous access evaluation | No |
Sign-in error code | 50207 |
Failure reason | This web native bridge interrupt will be shown to the user during login when the application is requesting login through the native broker and needs eSTS to ensure the broker is properly configured. |
Additional Details | MFA requirement satisfied by claim in the token |
EDIT: I engaged in a discussion with the IT Department, which led to the successful removal of the Group Policy that enforced the Windows Accounts extension. This resolution effectively addresses the problem for our internal users at present. Nevertheless, we must consider our numerous external users, as some of them might encounter similar policy-related challenges. Before confidently upgrading to the latest MSAL, we need to ensure that this particular issue is fully resolved for all user types.
Also running into this issue too. Any chance of a fix soon? High priority here as it makes it impossible to use an application we're trying to release. We could downgrade angular versions but that seems like overkill
@jo-arroyo This issue happens when trying to use Postman as well.
Any workaround for this that doesn't require uninstalling Windows Accounts?
@jo-arroyo This issue happens when trying to use Postman as well.
What is the url you're hitting in postman?
Any workaround for this that doesn't require uninstalling Windows Accounts?
Turning off the allowNativeBroker
flag is the workaround, we do not recommend uninstalling the extension as it may still be required by policy.
If someone could send me a fiddler trace (email on my profile) I'll see if I can determine what's happening
@tnorling
Turning off native brokers result in an "AADSTS70018: Invalid verification code"-error instead of the "AADSTS900144: The request body must contain the following parameter: 'client_id'"-error. See my previous comment.
Can you please send me a fiddler trace of this behavior?
Can you please send me a fiddler trace of this behavior?
It seems like I spoke a bit too early...
I changed the allowNativeBroker in our environment.ts-file, but never used the attribute when creating the instance of PublicClientApplication
.
After I explicitly set it to false, which I originally thought I had, it works with and without the Windows Accounts Extension.
Sorry for the inconvenience! :-)
Hello, allowNativeBroker: false, Works for me. Thanks you
export const msalConfig: Configuration = {
auth: {
//NAM - Carga de los valores desde el environment.
clientId: environment.clientId, // This is the ONLY mandatory field that you need to supply.
authority: environment.authority, // Defaults to "https://login.microsoftonline.com/common"
redirectUri: environment.redirectUri, // Points to window.location.origin. You must register this URI on Azure portal/App Registration.
postLogoutRedirectUri: environment.postLogoutRedirectUri, // Indicates the page to navigate after logout.
navigateToLoginRequestUrl: environment.navigateToLoginRequestUrl, // If "true", will navigate back to the original request location before processing the auth code response.
},
cache: {
cacheLocation: BrowserCacheLocation.LocalStorage, // Configures cache location. "sessionStorage" is more secure, but "localStorage" gives you SSO between tabs.
storeAuthStateInCookie: isIE, // Set this to "true" if you are having issues on IE11 or Edge
},
system: {
loggerOptions: {
loggerCallback(logLevel: LogLevel, message: string) {
//console.log(message);
},
logLevel: LogLevel.Verbose,
piiLoggingEnabled: false
},
allowNativeBroker: false, // Disables WAM Broker //https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/6169
}
}
I have a similar problem but in Edge (Version 115.0.1901.188).
The App is hosted in a Web App within an App Service Plan.
Angular ^16.1
"@azure/msal-angular": "^3.0.0-beta.1",
"@azure/msal-browser": "^3.0.0-beta.1",
The authority page https://login.microsoftonline.com is modificated within the company I am working with. I am not sure if that is the reason why the token is not saved properly but I couldn't rule it out either.
For me it seems it will authenticate successfully against AzureAD (after logging in with my credentials, even SSO works here somehow) but when I come back to my website it will still have no token in localStorage.
[Thu, 03 Aug 2023 14:59:14 GMT] : msal.js.browser@3.0.0-beta.1 : Info - handleRedirectPromise did not detect a response hash as a result of a redirect. Cleaning temporary cache. app.module.ts:43 [Thu, 03 Aug 2023 14:59:14 GMT] : @azure/msal-browser@3.0.0-beta.1 : Info - Emitting event: msal:handleRedirectEnd
@NgModule({
declarations: [
AppComponent
],
imports: [
BrowserModule,
HttpClientModule,
MsalModule.forRoot(new PublicClientApplication
(
{
auth:{
clientId:'<ClientId>',
redirectUri:'https://<domain>.net/.auth/login/aad/callback',
authority:'https://login.microsoftonline.com/<TenantId>'
},
cache:
{
cacheLocation: BrowserCacheLocation.LocalStorage,
storeAuthStateInCookie:false
},
system: {
allowNativeBroker: false,
loggerOptions: {
logLevel: LogLevel.Verbose,
loggerCallback: (level, message, containsPii) => {
if (containsPii) {
return;
}
switch (level) {
case LogLevel.Error:
console.error(message);
return;
case LogLevel.Info:
console.info(message);
return;
case LogLevel.Verbose:
console.debug(message);
return;
case LogLevel.Warning:
console.warn(message);
return;
}
},
piiLoggingEnabled: false
}
}
}
),
{
interactionType:InteractionType.Redirect,
authRequest:{
scopes:['User.Read']
}
},
{
interactionType:InteractionType.Redirect,
protectedResourceMap:new Map(
[
['https://graph.microsoft.com/v1.0/me',['user.Read']],
['https://domain.net',['api://apiUri/api.scope']]
]
)
},
)
],
providers: [{
provide:HTTP_INTERCEPTORS,
useClass:MsalInterceptor,
multi:true
},MsalGuard],
bootstrap: [AppComponent, MsalRedirectComponent]
})
=> checkAccessToken() always results in 'No accounts found'
isUserLoggedIn:boolean=false;
private readonly _destroy=new Subject<void>();
constructor(@Inject(MSAL_GUARD_CONFIG) private msalGuardConfig:MsalGuardConfiguration,
private msalBroadCastService:MsalBroadcastService,
private authService:MsalService,
private httpClient : HttpClient){}
ngOnInit(): void {
this.checkAccount();
this.msalBroadCastService.msalSubject$
.pipe(
filter((msg: EventMessage) => msg.eventType === EventType.LOGIN_SUCCESS || msg.eventType === EventType.ACQUIRE_TOKEN_SUCCESS),
takeUntil(this._destroy)
)
.subscribe((result) => {
this.checkAccount();
});
}
checkAccount() {
this.isUserLoggedIn = this.authService.instance.getAllAccounts().length > 0;
console.log("isUserLoggedIn", this.isUserLoggedIn);
}
ngOnDestroy(){
this._destroy.next(undefined)
this._destroy.complete();
}
async checkAccessToken() {
try {
const account = this.authService.instance.getAllAccounts()[0];
if (!account) {
console.log('No accounts found');
return;
}
const result = await this.authService.instance.acquireTokenSilent({
account,
scopes: ['User.Read']
});
console.log('Access token:', result.accessToken);
} catch (err) {
console.error(err);
}
}
Hello,
I was encountering the same issue on the beta versions. Edge working, Chrome not working with the specified error. Application was hosted on IIS.
The workaround worked, but then I also tried upgrading the versions to the latest ( msal-angular@3.0.4 and msal-browser@3.1.0 ) and the issue was fixed in one of the non beta versions.
I'm proposing this issue for closure.
Thank you!
Hello,
I was encountering the same issue on the beta versions. Edge working, Chrome not working with the specified error. Application was hosted on IIS.
The workaround worked, but then I also tried upgrading the versions to the latest ( msal-angular@3.0.4 and msal-browser@3.1.0 ) and the issue was fixed in one of the non beta versions.
I'm proposing this issue for closure.
Thank you!
Not fixed in versions:
"@azure/msal-angular": "3.0.6",
"@azure/msal-browser": "3.3.0"
Update: Still have an issue with the newest version "@azure/msal-angular": "3.0.7", "@azure/msal-browser": "3.4.0"
workaround with allowNativeBroker: false not working.
Closing as this has been resolved by the service.
Core Library
MSAL.js (@azure/msal-browser)
Core Library Version
3.0.0-beta.0
Wrapper Library
MSAL Angular (@azure/msal-angular)
Wrapper Library Version
3.0.0-beta.0
Public or Confidential Client?
Public
Description
Chrome is unable to get a token. If I open my site with Edge everything works as expected. The app is published to an IIS website.
Error Message
AADSTS900144: The request body must contain the following parameter: 'client_id'.
Msal Logs
MSAL Configuration
Relevant Code Snippets
Reproduction Steps
Just going to the website in Chrome will fail.
Expected Behavior
Should get a token and work, as it does in Edge.
Identity Provider
Azure AD / MSA
Browsers Affected (Select all that apply)
Chrome
Regression
No response
Source
External (Customer)