[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report
[ ] Performance issue
[x] Feature request
[ ] Documentation issue or request
[ ] Other... Please describe:
This issue is not browser-specific
@azure/msal-angular 0.1.4
Consider the following example with two routes:
{
path: '',
loadChildren: () => import('./components/start/start.module').then(m => m.StartModule)
},
{
path: 'demo',
loadChildren: () => import('./notifications/tab1.module').then(m => m.Tab1PageModule),
canActivate: [MsalGuard]
},
The /demo endpoint has the MsalGuard, but the root / endpoint hasn't. Let's say our base URL is http://localhost:8100.
In Azure AD B2C, it is only possible to set exact reply URLs; wildcard endpoints like http://localhost:8100/* are not allowed. Therefore, we always need to set the redirectUri to http://localhost:8100 or we'll get a redirect_uri_mismatch error from Microsoft's server.

Now, because our root endpoint / doesn't have the MsalGuard on it, when we get redirected back from Microsoft after logging in, the JWT in the URL hash isn't parsed (since MsalService is only triggered in the MsalGuard which triggers the processHash() function).
For now, as a workaround we created a /login endpoint in our Angular app and added http://localhost:8100/login as a redirect URI in the Azure AD B2C config. We put the MsalGuard on the /login endpoint so that the token in the URL hash is parsed correctly after logging in.
Please consider triggering the processHash() function e.g. in the MsalModule instead of in the MsalService (as this service is only constructed when MsalGuard is set on an endpoint).
See example above
@dennisameling Thanks for the context, very helpful. We are currently working on a new major version of the msal-angular package, and will consider including a fix for this (if not immediately, then as a follow-on enhancement).
@jasonnutter thank you, let me know if I can be of any help (like providing a PR)! I didn't make one immediately, since I don't know what your plans with the next major version are. 馃憤馃徏
@dennisameling Have you have a chance to try MSAL Angular v1? Based on the behavior in the samples, processing of the hash should still occur on pages that don't have the MsalGuard. Let us know if that is not the case, thanks!
This issue has not seen activity in 14 days. It may be closed if it remains stale.
Oops sorry, missed your reply. We switched to https://github.com/moberwasserlechner/capacitor-oauth2 in our project as we needed native authentication on iOS/Android as well, but thanks a lot for fixing it and congrats on launching the 1.x version of the library! Will check it out at a later stage 馃殌
Most helpful comment
@dennisameling Thanks for the context, very helpful. We are currently working on a new major version of the
msal-angularpackage, and will consider including a fix for this (if not immediately, then as a follow-on enhancement).