First navigation after sign-in performs extra redirection and returns to homepage

[johndowns]

Currently there are two redirects to get the access token, the first one to authenticate and receive the ID token and the second one to SSO and receive the access token. This manifests as the first navigation after sign-in being apparently ignored (although it is actually redirected to the app homepage with a query string parameter of ?state=xxx).

It would be preferable to have both tokens issued at once by using response_type=id_token token and having the SPA handle the receipt of both tokens at once.

[johndowns]

@blckqdrnt would you have time to look at this please?

[blckqdrnt]

I am not able to replicate this. It's working fine for me. I've trimmed the id_token code from the authGuard to avoid confusion.

My flow is,

1. User lands on home page
2. User goes to signin screen
3. User returns to homepage
   .
   .
   .
4. Token expires
5. User is redirected to auth url and back to page he was browsing.

[johndowns]

Thanks @blckqdrnt - could you try this on the test site (https://soscafevendoruiproxytest.azurewebsites.net) in an incognito window please? I can reliably reproduce this issue so I'm wondering if it's different when it runs on the server vs. locally?

[blckqdrnt]

Ahh! I see what you mean.

This is not a double redirect. It's the auth guard in action. The auth logic does not request an id_token, it requests an access_token directly. Let me tell you how,

1. On visiting https://soscafevendoruiproxytest.azurewebsites.net/ if I am not logged in, it redirects me to the SSO page https://soscafetest.b2clogin.com/soscafetest.onmicrosoft.com/b2c_1_signupsignin/oauth2/v2.0/authorize?client_id=.....

2. After I enter my credentials, it brings me back to https://soscafevendoruiproxytest.azurewebsites.net/, which is the redirect URL.

I think this is where the confusion lies. As per the app-routing.module, the base url / is to redirect to /vendors. So, if I was to give the redirect_url as /vendors, the SSO would redirect to the /vendors url, authguard intervenes and does its magic and it doesnt look like a double redirect. I chose to leave the redirect_url as / because most apps have a landing page at / with a link to a sub page like /vendors.

If you check app/src/guard/auth.guard.ts :: line 63. You will see that, redirect_uri=${environment.appBaseUrl} and response_type=token
There is no request for id_token. This is a one step auth which directly gets token.

[blckqdrnt]

I've also noticed a routing bug.

1. Log in
2. Arrive at /vendors
3. Click on a vendor from the list

It will initiate the auth workflow once again.

This is a routing issue. In the vendor-list.component.html file, line 27, the address to route /vendors/:id is done incorrectly. It shouldn't be ['/vendors/', row.id], but should be ['/vendors/'+row.id] I'm not clear why the router behaves differently in this scenario but the above mentioned change fixes that issue. If you merge my pending pull requests, I can make a hotfix for this issue too.

[johndowns]

Thanks @blckqdrnt - good catch. I've merged the pending PRs - if you are able to do a hotfix for this that would be awesome :)

[blckqdrnt]

PR with hotfix made

[johndowns]

Thanks @blckqdrnt - that hotfix has been deployed to the test environment but the double redirection is still happening. Is the hotfix intended to fix that issue or is it a separate thing?

cc FYI @JackDownsNZ

[blckqdrnt]

Hi @johndowns the hotfix was for internal linking, which is related to the extra redirect, but I am still not able to understand what you mean with the double redirect. I have explained the workflow in my comments above.

If you want we can catch up over Zoom and claarify the confusion.

[johndowns]

@blckqdrnt Thanks. I've read through your earlier comment again and I'm wondering whether we just need to change the redirect URL to /vendors - does that sound right?

Just to be 100% clear, here's a short video I recorded to show what I'm seeing.

The sequence is:

1. I log in (at 00:20)
2. The homepage loads (at 00:26)
3. I click the 'Register a new business' link (at 00:31)
4. The homepage reloads (at 00:34)
5. I click the 'Register a new business' link again (at 00:36)
6. The 'Register a new business' page then loads (at 00:37).

So the extra redirection is step 4 in this sequence. I'm not clear whether the issue is that the redirect URL from B2C or not - this didn't happen with the MSAL implementation though, and that had the same redirect URL. Also you can see in browser tools that at step 4, it makes a sequence of network calls including a GET to the AAD authorize endpoint with response_type=token, which returns a 302.

Do you think this is just that the redirect URL needs to change? I can try that on the test site if so - just let me know where to make the change in the Angular app.

[blckqdrnt]

Thanks for the video @johndowns the PR was meant to address this. When I tested my fix, it was working as expected but now its not. Let me deal with this, I'll keep you posted.

[blckqdrnt]

Hi @johndowns apparently there was a breaking change (not very well documented) in the way angular 9 handles guard constructors.

I moved all logic from the constructor to canActivate and it does the trick on my local. Can you test and let me know?

[johndowns]

Nice one - that seems to have done it! Thank you :)

[blckqdrnt]

Cool. Learnt something new today.