microsoft-authentication-library-for-js: (Cancel button) Error - Guard - error while logging in, unable to activate

Core Library

MSAL.js v2 (@azure/msal-browser)

Core Library Version

2.21.0

Wrapper Library

MSAL Angular (@azure/msal-angular)

Wrapper Library Version

2.1.0

Description

I am integrating B2C the same way as it’s described in https://github.com/Azure-Samples/ms-identity-javascript-angular-tutorial/tree/main/3-Authorization-II/2-call-api-b2c in my project

My app has “/panel/settings” Component, which is protected by MsalGuard:

const panelRoutes = [
  { path: '', component: PanelHomeComponent },
  { path: 'settings', component: PanelSettingsComponent },
];

const routes: Routes = [
  { path: 'panel', component: PanelComponent, canActivate: [MsalGuard], children: panelRoutes },
];

I implemented EditProfile button (redirect) there. It works ok when I update the profile (it redirects me to “/panel/settings” without any issues). But there is a problem when I click a Cancel button (default EditProfile user flow). Logs: image

Steps and redirects:

  1. I click the Cancel button on the default EditProfile B2C page
  2. Auto-redirect to https://localhost:4200/
  3. Auto-redirect to https://localhost:4200/panel/settings
  4. Auto-redirect to https://localhost:4200/ (wrong)

When I try to click Login button again on the landing page after all auto-redirects: image

Angular: 13.0.2 .NET Core: 6

MSAL Configuration is the same as in https://github.com/Azure-Samples/ms-identity-javascript-angular-tutorial/tree/main/3-Authorization-II/2-call-api-b2c (different clientId, etc params ofc)

MSAL Configuration

No response

Relevant Code Snippets

No response

Identity Provider

Azure B2C Basic Policy

Source

Internal (Microsoft)

About this issue

  • Original URL
  • State: open
  • Created 2 years ago
  • Comments: 15 (1 by maintainers)

Most upvoted comments

It indicates that loginPopup or loginRedirect/handleRedirectPromise threw an error which resulted in the user not being logged in

Just for clarification on your suggestion. You are suggesting we rebuild the MSAL Guard and add the catchError on the handleRedirectObservable?

Correct. The current behavior of the MSAL Guard naiivly assumes that when a redirect returns an error it means that the user should not have access to the guarded route. This is not an accurate assumption when trying to sign a 2nd user in or when working with B2C where you might be invoking interaction to go to the profile edit or password reset policy rather than to sign a user in. You should modify the existing MSAL Guard catchError handler to check whether or not a user was already signed in when this error was thrown. If there is a user signed in you can activate the Guard - if not you can use the existing behavior to render the login failed route.

Also what page should get the handle handleRedirectObservable? The page that initiated the password reset or the page that we are redirecting to.

Short answer: both. Long answer: handleRedirectObservable should be run on all pages that will be hit after the redirect to the IDP. By default handleRedirectObservable called on the redirectUri page will redirect you to the calling page and then handleRedirectObservable called on the calling page will handle the response.

Same issue with password reset. Because of the way the redirect response handled in this scenario the handleRedirectPromise always returns the existing response which is AuthError received from the redirection. There might be a proper way to handle but for quick fix this custom implementation might help.

Override the handleRedirectPromise method and check the error code and delete the response cache if the error exists in existing redirect response.

export class CustomPublicClientApplication extends PublicClientApplication implements IPublicClientApplication { override async handleRedirectPromise(hash?: string): Promise<AuthenticationResult | null> { let response = this.redirectResponse.get(hash || Constants.EMPTY_STRING); if (typeof response !== "undefined") { response.then(x => { }).catch(error => { if (error instanceof AuthError) { if (error.errorMessage.indexOf("AADB2C90091") > -1) { this.redirectResponse.delete(hash); } } }); } return super.handleRedirectPromise(hash) } }

Use this CustomPublicClientApplication class as your MSAL instance provider factory.

@EvgenStudent Thanks for clarifying. I was able to reproduce this behavior and agree this is something we can and should improve. I’ve marked this as a bug and added an item in our backlog to investigate the best way to solve this as this would affect any scenario where at least one user is signed-in and an interactive request fails. In the meantime I would suggest copying the Guard and modifying the behavior here to catch this error and let the guard activate in this scenario. We’ll update this issue when we have an official solution

@tnorling Even if I remove loginFailedRoute in my MsalGuard, everything works the same, but now my landing page is blank after all redirects. I think, since EditProfile is canceled (== auth is failed), it can not activate the guard. But I already have an ActiveAccount in MsalService created by SignUpSignIn policy.

Behavior what I expect is redirect to the initial “/panel/settings” (where EditProfile button is) after EditProfile cancelation.