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:
Steps and redirects:
- I click the Cancel button on the default EditProfile B2C page
- Auto-redirect to https://localhost:4200/
- Auto-redirect to https://localhost:4200/panel/settings
- Auto-redirect to https://localhost:4200/ (wrong)
When I try to click Login button again on the landing page after all auto-redirects:
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)
It indicates that loginPopup or loginRedirect/handleRedirectPromise threw an error which resulted in the user not being logged in
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.
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 myMsalGuard
, 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.