Microsoft-authentication-library-for-js: [MSAL for Angular] Sending GET request to undefined url on Auth

[nfgallimore]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Other... Please describe:

Browser:

• [x] Chrome version XX
• [ ] Firefox version XX
• [ ] IE version XX
• [ ] Edge version XX
• [ ] Safari version XX

Library version

Library version: 0.1.2

Current behavior

I have to clear my local storage and logout of Microsoft to access my angular application after not visiting it for an extended period of time. It was previously working, now I get the following error in chrome console:

GET https:/login.microsoftonline.com//oauth2/v2.0/undefined 404 (NOT FOUND).

For some reason it is sending a GET request with a /undefined attached to the end of it.

Expected behavior

I expect to not have to clear my local storage / logout of of Microsoft to use my app.

Minimal reproduction of the problem with instructions

Wait for access token to expire in browser's local storage. I.e.., when I try to visit the angular app in morning after not using the app overnight. I have to clear my local storage and logout of Microsoft to access the angular application.

More details

I am using the MSAL Angular library with the interceptor. I have it setup to use my app id and have just added the [MsalGuard] to my routes. In my app.module I have

MsalModule.forRoot({ clientID: environment.clientId, authority: 'https://login.microsoftonline.com/<App-ID>/', redirectUri: environment.redirectUri, cacheLocation : 'localStorage', protectedResourceMap : [ [environment.apiUrl, [environment.apiScope]] ] }),

Nothing got changed in this part of the app.module.ts, and with these settings before it was not producing this error. Does anyone have an idea on where I could start to debug this? It's seems incredibly hard to debug or to track down what the cause of this is.

[nfgallimore]

@jasonnutter I will try to update with more details, but the details seem to be lacking for this issue.

[mlindberg]

I'm having this exact problem. It happens during silent token renewal after the user hasn't been active on the site awhile. I get a single call to undefined for each msal token renewal frame, followed by a token renewal timeout error.

{_error: "Token renewal operation failed due to timeout", _errorDesc: "Token Renewal Failed", _scopes: ""}

[nfgallimore]

Are you subscribing to the event acquireTokenFailure and then silently trying to reacquire? That's what I had to do to fix it. I did it in the app component:

import { Component, OnInit } from '@angular/core';
import { MsalService, BroadcastService } from '@azure/msal-angular';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.scss']
})
export class AppComponent implements OnInit {

  constructor(
    private msalService: MsalService,
    private broadcastService: BroadcastService) {
  }

  ngOnInit() {
    const sub = this.broadcastService.subscribe('msal:acquireTokenFailure', () => {
      sub.unsubscribe();
      this.msalService.loginRedirect();
    });
  }
}

[Ivan-L]

@jasonnutter I can confirm that we are also getting this same error with @azure/msal-angular 0.1.4-beta.2. Our repro steps are exactly the same, whenever somebody accesses the app for the first time in the day, a GET to https://login.microsoftonline.com/[tenant_id]/oauth2/v2.0/undefined is made. The only recovery from that issue is to clear the local/session storage. I haven's tested whether this is resolved in the new msal-angular beta, but for now we're stuck with @azure/msal-angular 0.1.4-beta.2 until the other issue I reported is resolved.

@nfgallimore I did try your workaround, however one needs to filter out certain broadcasts for this to work. For example, when using acquireTokenPopup and then the user closes the popup, the msal:acquireTokenFailure event is fired with an errorCode of user_cancelled. In that case we do not want to redirect. I still need to dig into exactly what type of error needs to be caught to handle only the "undefined" URL error case.

[jasonnutter]

We have determined this is a bug in login.microsoftonline.com, not the library itself. The service team is triaging now.

[kemins]

it looks like a blocker, any ETA when it might be solved

[jasonnutter]

@kemins Not at this time, unfortunately. I'll follow up when I know more.

[developerWolf]

In our case, we found that blocking 3rd party was the cause of the issue. After enabling 3rd party cookies, everything behaved as expected.

Not sure why that results in the bad authorize url.

[jasonnutter]

@developerWolf Good to know. Third-party cookies are required regardless, as the library relies on them when acquiring tokens.

[jasonnutter]

I believe this has been fixed, please let us know if not.

Closing.