Microsoft Azure AD takes longer time on initial load with same setup

For some reason, if I change scope, issuer and clientId in AuthConfig, then loading takes (I timed) ~5sec as in Initializing message is blinking for 5 seconds. Happens only while user is not signed in. After sign in is done, refreshing page loads it in expected time frame.

Also with Microsoft Azure AD it shows, that it is attempting to redirect to external link

ClientID: a3db960c-852a-4a0b-9b45-cb939562eee2 TenantID: 2d044a19-492e-4609-ab23-1a183a41dfe3 https://login.microsoftonline.com/2d044a19-492e-4609-ab23-1a183a41dfe3/oauth2/v2.0/authorize?response_type=code&client_id=a3db960c-852a-4a0b-9b45-cb939562eee2&state=Z0xidXNpbkMxcWx6VmJHQU5TYmNRR3I1R3BrbEZHVnFlNGwxRDZ0T25NekVv&redirect_uri=http%3A%2F%2Flocalhost%3A4200%2Fsilent-refresh.html&scope=openid api%3A%2F%2Fa3db960c-852a-4a0b-9b45-cb939562eee2%2Fapp&code_challenge=wainyA2LBDvc7Lvjpvus9DuZ0Kk5a05Zt1jhYDMAgHk&code_challenge_method=S256&nonce=Z0xidXNpbkMxcWx6VmJHQU5TYmNRR3I1R3BrbEZHVnFlNGwxRDZ0T25NekVv&prompt=none&iframe-request-id=95cd23ee-00a2-4e02-9e9f-881319050400

[jeserkin]

Huge thank you.

[jeroenheijmans]

I had to configure a few extra things based on all comments above to reproduce the issue in Chrome on Windows. Here’s a git diff from current main to see what’s going on:

 export const authConfig: AuthConfig = {
-  issuer: 'https://demo.duendesoftware.com',
-  clientId: 'interactive.public', // The "Auth Code + PKCE" client
+  issuer: 'https://login.microsoftonline.com/2d044a19-492e-4609-ab23-1a183a41dfe3/',
+  clientId: 'a3db960c-852a-4a0b-9b45-cb939562eee2',
+  strictDiscoveryDocumentValidation: false,
+  skipIssuerCheck: true,
+  requireHttps: false,
   responseType: 'code',
   redirectUri: window.location.origin + '/',
   silentRefreshRedirectUri: window.location.origin + '/silent-refresh.html',
-  scope: 'openid profile email api', // Ask offline_access to support refresh token refreshes
+  scope: 'openid profile email', // Ask offline_access to support refresh token refreshes
   useSilentRefresh: true, // Needed for Code Flow to suggest using iframe-based refreshes
   silentRefreshTimeout: 5000, // For faster testing
   timeoutFactor: 0.25, // For faster testing

I run this with npm run start-with-ssl.

If you run with that you will see in Chrome on Windows after the 5ish second delay and then nothing. The console will yell at you:

Unsafe attempt to initiate navigation for frame with origin 'https://localhost:4200' from frame with URL 'https://login.microsoftonline.com/2d044a19-492e-4609-ab23-1a183a41dfe3/oauth2/authorize?response_type=code&client_id=a3db960c-852a-4a0b-9b45-cb939562eee2&state=MHkxWDBRbUlLS3Y1eVotTS5uaHJZNkJ4cXYtQUVKSmQxOTBIaFM4VXBOUUxE&redirect_uri=https%3A%2F%2Flocalhost%3A4200%2Fsilent-refresh.html&scope=openid%20profile%20email&code_challenge=b_5viMFmIj8uPOrUyyjfsQcYj8JPkaxuIhzjkJCtRLM&code_challenge_method=S256&nonce=MHkxWDBRbUlLS3Y1eVotTS5uaHJZNkJ4cXYtQUVKSmQxOTBIaFM4VXBOUUxE&prompt=none'. The frame attempting navigation is targeting its top-level window, but is neither same-origin with its target nor has it received a user gesture. See https://www.chromestatus.com/feature/5851021045661696.

If you use Firefox on Windows a different error furhter hints at the problem:

Sign in

Sorry, but we’re having trouble signing you in. AADSTS50058: A silent sign-in request was sent but no user is signed in. The cookies used to represent the user’s session were not sent in the request to Azure AD. This can happen if the user is using Internet Explorer or Edge, and the web app sending the silent sign-in request is in different IE security zone than the Azure AD endpoint (login.microsoftonline.com).

That strongly suggests to me that this code from the sample:

https://github.com/jeroenheijmans/sample-angular-oauth2-oidc-with-auth-guards/blob/e57fadbf1ce4eb3498db2a728350e0ec16409504/src/app/core/auth.service.ts#L108-L113

will not work with this particular Identity Provider.

You will need to switch to using refresh tokens, not use said part of the sample, or find a way to reconfigure Azure AD to support this scenario.

It’s weird to me, because their docs suggest prompt=none logins (silent logins) are supported but if you have to know beforehand whether it will succeed, that kind of defeats the purpose?

I hope that helps. Recommend looking for further support from the Azure AD side of things, don’t think we’ll change much here on this sample unfortunately. Hope that makes sense?