Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

MSAL Redirects with hash in url

I'm currently working on an application in angular 6 which uses AAD to authenticate users. Here i have used the library azure/msal-angular to connect to AAD v2. I've initialized the library with my client id as prescribed in the readme for the project, and i can login just fine.

The problem is: After i login i've setup a redirect url to: http://localhost:4200/account the landing page after login, where i want the user to come after a successful login. Here i've specified the route as such:

{ path: 'account', component: AccountDetailedComponent }

Which is fine, except the redirect url from AAD navigates to http://localhost:4200/account#id_token=xxxxx and for the life of me, i cannot get rid of the hashbang and id_token.

I would expect the id_token=xxxx to be a query param like so:

http://localhost:4200/account?id_token=xxxx

which would make my route match, but it doesn't, and therefore the route becomes invalid.

My question is: How can i solve the route to match the specified route?

I have read about matchers in routes, but can it really be that i should make regex' for matching a common redirect route? I don't see any option in the interface to remove this hashbang nor in the library.

Edit

The reason for thinking it was a route mismatch was, i got redirected to login page again, after the initial redirect to /account. It would flash /account#id_token=xxxx then redirect to login page again. My answer below describes the problem solved.

Hope you can help.

Kind regards Chris

like image 228
ChrisEenberg Avatar asked Sep 19 '25 05:09

ChrisEenberg


1 Answers

So i've actually solved my own question. The mistake i made was calling msalService.loginredirect() manually from within ngOnInit(). When the redirect to microsoft's page occured, i would login, and afterwards get sent back to my application. This would invoke the same msalService.loginRedirect() from the ngOnInit method, and thereby never get to the actual redirect.

From what i've been able to understand, the correct way of handling the login, is simply to apply a canActivate: [MsalGuard] on the specific route, and let the guard handle the redirect to the login screen, and when you come back, it'll redirect to the specified path without the hash.

I hope this helps others that tried doing what i did. I can elaborate more on my solution if anyone finds this confusing.

Kind regards Chris

like image 182
ChrisEenberg Avatar answered Sep 21 '25 20:09

ChrisEenberg