Microsoft-authentication-library-for-js: angular-msal 1.0.0 with angular 8 , msal-loginSuccess broadcast event fires twice and page is not redirect back to login is called?

Created on 21 Mar 2020  路  5Comments  路  Source: AzureAD/microsoft-authentication-library-for-js

I implemented @azure/angular-msal 1.0.0 with msal 1.2.2 in my angular 8 application , (that uses web api of .NET Core 3.1). I'm not understanding how logout works. My application requirement is like, on page load of any page it checks if login otherwise redirect to login page. But application not having logout functionality. So when in browser new tab, from azure portal user signed out, then application page changes, shouldn't it ask for login again? and how refresh token automatically works?

msal-angular question

Most helpful comment

@jasonnutter Are we correct to assume that the msal:loginSuccess event should only actually be firing once after a successful login, initiated by loginRedirect or loginPopup?

Yeah, that seems like a fair request.

All 5 comments

Searching the code base, the msal:loginSuccess event is getting _published_ from two source files: msal.service.ts and msal-guard.service.ts.

It seems to me that the event should not be published from the latter file. In the current scheme of things, you will also be notified for the msal:loginSuccess event whenever the route guard successfully acquires a token from the cache.

Also, refer issue #1392 (Why guard on acquireTokenSilent broadcasts msal:loginSuccess and not just msal:acquireTokenSuccess?). To me, the _guard_ should not be publishing any of the msal:* events as they are already published by the _core_ service (msal.service.ts).

Searching the code base, the msal:loginSuccess event is getting _published_ from two source files: msal.service.ts and msal-guard.service.ts.

It seems to me that the event should not be published from the latter file. In the current scheme of things, you will also be notified for the msal:loginSuccess event whenever the route guard successfully acquires a token from the cache.

Also, refer issue #1392 (Why guard on acquireTokenSilent broadcasts msal:loginSuccess and not just msal:acquireTokenSuccess?). To me, the _guard_ should not be publishing any of the msal:* events as they are already published by the _core_ service (msal.service.ts).

Thanks for your reply. But I'm not getting your point. In my app.module.ts I have added msalModule.forroot({.... different property}) and in app.component.ts I added handleredirectcallback, msal:loginsuccess broadcast event. and in app.routing.ts I added canActivate:[msalGuard].

Thanks @gulench for the research. I was trying to figure out why we're receiving the msal:loginSuccess event 3 times in a row after the initial login.

@jasonnutter Are we correct to assume that the msal:loginSuccess event should only actually be firing once after a successful login, initiated by loginRedirect or loginPopup?

I implemented @azure/angular-msal 1.0.0 with msal 1.2.2 in my angular 8 application , (that uses web api of .NET Core 3.1). I'm not understanding how logout works. My application requirement is like, on page load of any page it checks if login otherwise redirect to login page. But application not having logout functionality. So when in browser new tab, from azure portal user signed out, then application page changes, shouldn't it ask for login again? and how refresh token automatically works?

@llakhani The MSAL guard uses msal.getAccount() to determine whether or not the user is logged in, and that only gets reset if the you call logout from your application (as it uses information stored in local/session storage on your domain). MSAL will not know that your AAD session is no longer active (i.e. you logged out from the Azure portal) until it needs to make a network request to acquire token.

The way for MSAL to verify if you still have an active AAD session is to call acquireTokenSilent with the clientId as the only scope, which the MSAL Guard does if getAccount() is populated.

Looking at the Guard again, there are some issues with how this is implemented:

  • No clear differentiation between regular login calls and calls initiated from the Guard
  • acquireTokenSilent will use the cache by default, so in this situation it should potentially have forceRefresh set to true to ensure a network request is made.
  • acquireTokenSuccess and loginSuccess are both broadcasted for the same operation.

@jasonnutter Are we correct to assume that the msal:loginSuccess event should only actually be firing once after a successful login, initiated by loginRedirect or loginPopup?

Yeah, that seems like a fair request.

Was this page helpful?
0 / 5 - 0 ratings