Closed kevveh closed 8 months ago
tnorling
commented
9 months ago Response header [Location]: http://localhost/auth#code=... --> http://localhost/auth is my redirect URL
This is your problem. The #code should not be removed and is preventing MSAL from processing the response. You likely have some routing behavior that is stripping the hash. More information about this error here
kevveh
commented
9 months ago @tnorling , it doesn't look like the navigation is happening (when receiving a response in the iFrame).
Just to clarify: my redirectUri = http://localhost/auth. In devtools, I can see a call (name = authorize?...) with a status 302. When I inspect this call, I see "Location" in the response headers, with a value http://localhost/auth#code=...--> which is the hash I'm expecting.
I've tried the configuration suggested here.
I've added the following path in my routing module:
{ path: 'code', component: LoginPage },
I've added the handleRedirectObservable as suggested here in ngOnInit (in my login page).
Router is configured as follows:
@NgModule({ imports: [ RouterModule.forRoot(routes, { useHash: true, onSameUrlNavigation: 'reload', // Don't perform initial navigation in iframes initialNavigation: !BrowserUtils.isInIframe() ? 'enabledNonBlocking' : 'disabled', }) ], exports: [RouterModule] })
Perhaps also important: there is no /auth component. I'm just using this as a "dummy" route.
Are there any examples available that use ssoSilent with Angular router?
kevveh
commented
9 months ago Another test I did, I used a matcher in my router instead of checking for the path:
let isSsoSilentResponse: boolean = false; url.forEach((urlSegment) => { if (urlSegment.path.includes("auth#code=")) { isSsoSilentResponse = true; } }) return isSsoSilentResponse ? ({consumed: url}) : null;
Added the following to the routes: { matcher: pathMatcher, component: AuthComponent },
When I directly call the link from the response header (this.router.navigate(['http://localhost/auth#code=...]), I enter the AuthComponent (I can see it in the logging). However, when I perform the ssoSilent call, I don't (doesn't show the expected logging + get the timeout).
tnorling
commented
9 months ago In devtools, I can see a call (name = authorize?...) with a status 302. When I inspect this call, I see "Location" in the response headers, with a value http://localhost/auth#code=...--> which is the hash I'm expecting.
To clarify, are you saying that the iframe doesn't actually 302 and gets stuck on the login.microsoftonline.com domain?
Perhaps also important: there is no /auth component. I'm just using this as a "dummy" route.
What happens if you do set this up?
Are there any examples available that use ssoSilent with Angular router?
Not ssoSilent but all of our Angular samples demonstrate router configuration + acquireTokenSilent. If you pass cacheLookupPolicy: CacheLookupPolicy.Skip as part of the request object to acquireTokenSilent (or the Interceptor config) you can force it to use the same underlying flow ssoSilent uses.
kevveh
commented
9 months ago Not ssoSilent but all of our Angular samples demonstrate router configuration + acquireTokenSilent. If you pass cacheLookupPolicy: CacheLookupPolicy.Skip as part of the request object to acquireTokenSilent (or the Interceptor config) you can force it to use the same underlying flow ssoSilent uses.
I've already tried this, but got the same error (monitor_window_timeout).
What happens if you do set this up?
I've configured the following:
export function pathMatcher(url: UrlSegment[]) {
console.log("PATHMATCHER | URL = ", url);
let isSsoSilentResponse: boolean = false;
url.forEach((urlSegment) => {
if (urlSegment.path.includes("auth#code=")) {
isSsoSilentResponse = true;
}
})
return isSsoSilentResponse ? ({consumed: url}) : null;
}
const routes: Routes = [
{ path: 'menu', loadChildren: () => import('./menu/menu.module').then(m => m.MenuPageModule), canActivate: [MsalGuard]},
{ path: 'login', loadChildren: () => import('./login/login.module').then(m => m.LoginPageModule)},
{ matcher: pathMatcher, component: AuthComponent },
{ path: '', pathMatch: 'full', redirectTo: '/login'},
{ path: '**', redirectTo: '/login'},
];
@NgModule({
imports: [
RouterModule.forRoot(routes,
{
useHash: true,
onSameUrlNavigation: 'reload',
// Don't perform initial navigation in iframes
initialNavigation: !BrowserUtils.isInIframe() ? 'enabledNonBlocking' : 'disabled',
})
],
exports: [RouterModule]
})
export class AppRoutingModule {
}@Component({
selector: 'app-home',
template: ''
})
export class AuthComponent implements OnInit {
constructor(private msalService: MsalService) {}
ngOnInit(): void {
console.log("AUTHCOMPONENT:LOGIN");
this.msalService.handleRedirectObservable().subscribe({ next: (result: AuthenticationResult) => {
console.log("AUTHCOMPONENT:LOGIN | HANDLEREDIRECTOBSERVABLE");
if (result) {
console.log("AUTHCOMPONENT:LOGIN | HANDLEREDIRECTOBSERVABLE:RESULT");
} else {
console.log("AUTHCOMPONENT:LOGIN | HANDLEREDIRECTOBSERVABLE:NO_RESULT");
}
},
error: (error) => {
console.log("AUTHCOMPONENT:LOGIN | HANDLEREDIRECTOBSERVABLE:ERROR = ", error);
}});
}
}To clarify, are you saying that the iframe doesn't actually 302 and gets stuck on the login.microsoftonline.com domain?
I call ssoSilent by pressing a button. When I press it, the following code is executed:
this.msalService.instance.ssoSilent({
...this.msalGuardConfig.authRequest,
account: account
})
.then(() => {
console.log("AUTH_SERVICE | ACQUIRE_TOKEN_SSOSILENT:SUCCESS");
})
.catch((error) => {
console.log("AUTH_SERVICE | ACQUIRE_TOKEN_SSOSILENT:ERROR = ", error);
});When I press the button, I see the following in DevTools:
When I inspect the authorize?client_id=... call, I can see the following:
However, in my logging, I see a monitor_window_timeout. I don't see any of my logging indicating success (only SSOFAILURE, because of the timeout).
I've also tried replacing the ssoSilent call (when pressing the button) with the contents of the "Location" header:
this.router.navigate(['http://localhost/auth#code=...']
When I do this, I do end up in my AuthComponent (I see the logging), however, it's the following logging: AUTHCOMPONENT:LOGIN | HANDLEREDIRECTOBSERVABLE:NO_RESULT
So, to summarize:
monitor_window_timeout (while I'm getting a 302 response)this.router.navigate(['http://localhost/auth#code=...']), I do end up in my AuthComponent, however, the handleRedirectObservable does not seem to process the result.tnorling
commented
9 months ago From your screenshot of the network requests it looks like the /auth route failed to load. Can you see if there's any more detail there? Do you happen to have any CSPs applied such as X-Frame-Options that might prevent loading your site inside iframes?
kevveh
commented
9 months ago If there are any CSPs applied, it's by default, because none are currently set (by me). I'm using Ionic (which I know is not currently supported) on an Android device.
BrianMikinski
commented
9 months ago FWIW - I've also get a similar setup and am seeing the same issue in MSAL 2 and experiencing the same issue with not being able to redirect as well. I've got my redirect uri properly configured in the app registration. Starting to get stumped by this one...
BrianMikinski
commented
9 months ago FWIW - I've also get a similar setup and am seeing the same issue in MSAL 2 and experiencing the same issue with not being able to redirect as well. I've got my redirect uri properly configured in the app registration. Starting to get stumped by this one...
Doing some more research here and it looks like I might be getting throttled. I was able to see a AADSTS50196 message that came back in the iframe
AADSTS50196
kevveh
commented
9 months ago Doing some more research here and it looks like I might be getting throttled. I was able to see a AADSTS50196 message that came back in the iframe
I don't think this is my problem (depening on how much time needs to be between requests). I'm still getting the error when I leave 10+ minutes between ssoSilent requests.
binerdy
commented
9 months ago From your screenshot of the network requests it looks like the /auth route failed to load. Can you see if there's any more detail there? Do you happen to have any CSPs applied such as X-Frame-Options that might prevent loading your site inside iframes?
In DevTools I see the following error: Refused to display 'https://...' in a frame because it set 'X-Frame-Options' to 'deny'.
kevveh
commented
9 months ago @binerdy , any chance you can post a screenshot? Because I'm not getting that error (or I'm looking in the wrong place).
binerdy
commented
9 months ago @binerdy , any chance you can post a screenshot? Because I'm not getting that error (or I'm looking in the wrong place).
@kevveh Using Edge
kevveh
commented
9 months ago I'm not getting the X-Frame-Options error. just the timeout:
binerdy
commented
9 months ago @kevveh are you also using Edge Version 121.0.2277.98 (Official build) (64-bit)?
kevveh
commented
9 months ago Yes:
kevveh
commented
9 months ago Perhaps also of use, this is the iFrame that's created:
<iframe sandbox="allow-scripts allow-same-origin allow-forms" src="https://login.microsoftonline.com/...." style="visibility: hidden; position: absolute; height: 0px; width: 0px; border: 0px;"></iframe>
binerdy
commented
9 months ago I'm not getting the X-Frame-Options error. just the timeout: ...
Thanks, so I can safely exclude X-Frame-Options Deny as the root cause.
binerdy
commented
9 months ago @kevveh
Did you also start having this problem on the 1st of February? On that date our installed Edge version was released.
They fixed the following vulnerability: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-21399
This vulnerability could lead to a browser sandbox escape.
kevveh
commented
9 months ago @binerdy No, I've been having this problem since last year (tried some different things), but getting a token via ssoSilent has never worked (for my application).
tnorling
commented
9 months ago You both may be getting this error for different reasons. @binerdy The X-Frame-Options deny error is happening due to the throttling error. Some errors, such as throttling errors, thrown by the service do not get returned back to the application and are instead displayed to the user. Since this is happening inside an iframe you get an X-Frame error. Addressing the throttling error will address both the X-Frame & monitor_window_timeout errors in your case. If you need help with that I suggest opening your own issue.
@kevveh Any luck figuring out why the /auth route failed to load?
kevveh
commented
9 months ago @tnorling No, and I don't really know where to start looking. Like I said, it seems like everything is going as expected, except for the navigation. Giving that the only error I'm getting is the monitor_timeout, I'm a bit stuck (hence why I figured I'd post it here).
tnorling
commented
9 months ago We unfortunately can't help you with hosting issues specific to your app, we just don't have enough insight into your environment. Once you get your redirectUri page to respond/render we can take another look if you continue to experience issues.
kevveh
commented
9 months ago @tnorling , is there a way for me to check if the iFrame is redirecting (that you know of)?
tnorling
commented
9 months ago The network trace is pretty clear in this regard, pasting here again for reference:
You can see the frames currently rendered on the page (and their urls and CSPs) in the application tab of the browser dev tools. Setting a debugger and stepping through might help slow things down enough to catch it before it times out
kevveh
commented
9 months ago @tnorling , I've been looking at causes why the iFrame might not redirect, and I've found something relating to the sandbox.
This is the iFrame that's created: <iframe sandbox="allow-scripts allow-same-origin allow-forms" src="https://login.microsoftonline.com/...." style="visibility: hidden; position: absolute; height: 0px; width: 0px; border: 0px;"></iframe>. Is it possible allow-top-navigation needs to be added to the sandbox setting?
binerdy
commented
9 months ago Thanks for your help.
I think I found the cause of my problem. I added a can activate as a guard which caused the redirect to not work anymore. It was impossible to set the new acquired refreshToken.
chicken egg problem: My guard needs a permission which I can only retrieve with a valid bearer token
I removed my permission guard, now it works.
So it seems like multiple reroutes are needed, I have to rethink my solution.
kevveh
commented
9 months ago @tnorling , I've managed to sort out the redirect URI, and now I'm getting a response. However, I'm now getting 2 errors:
Unsafe attempt to initiate navigation for frame with URL 'http://localhost/#/menu/calendar' from frame with URL 'https://login.microsoftonline.com/...'. The frame attempting navigation of the top-level window is sandboxed, but the flag of 'allow-top-navigation' or 'allow-top-navigation-by-user-activation' is not set. --> (this seems to correspond with my earlier comment)
And
Uncaught DOMException: Failed to set the 'href' property on 'Location': The current window does not have permission to navigate the target frame to 'https://login.microsoftonline.com...
tnorling
commented
9 months ago Is it possible allow-top-navigation needs to be added to the sandbox setting?
No, if the iframe is attempting a top level navigation then something is wrong, the iframe should be completely isolated. This can happen for 2 reasons:
If you've confirmed the redirect back to your redirectUri is happening then it's reason 2 you're after. We typically recommend setting your redirectUri to a completely blank, static page to eliminate the chance of some logic in your app attempting a redirect.
If you think there's a chance it's reason 1 then you can try opening the login.microsoftonline.com url from the error message in a new tab and that should enable you to see the error the STS is attempting to show you.
kevveh
commented
8 months ago It's not navigating to my redirect URI (yet). I've noticed that my application was adding a # after localhost, so I added this to my redirectUri (http://localhost/#/auth).
After doing this, I get the 2 errors mentioned above (so, from my point of view, I get further than before). However, it seems that the current problem is that the application wants to redirect to http://localhost/#/auth, but is not allowed. As the errors suggests, it seems like the flag allow-top-navigation needs to be set in orde to complete the redirect.
tnorling
commented
8 months ago I see I missed where you're using hash routing. This is likely why you're having issues. Hashes are not allowed in redirectUri's, this is because the response is returned on the hash. Instead make your redirectUri just "http://localhost" (and make sure it's registered on the app registration) and you can set the redirectStartPage parameter to "http://localhost/#/auth" if that's where you want the user to ultimately land after everything is finished.
kevveh
commented
8 months ago I'm using hash routing as a test. The only reason I enabled it, was to see if that would work, given that there is a '#' in the response, and it seems Angular Router has some issues with the #.
I've tried your suggestion (about changing the redirectUri to "http://localhost"), but that doesn't work either - I get the exact same result as before:
With a response header:
As for the redirectStartPage, I'm using silent requests (ssoSilent), so I can't set this.
So, when I disable hash routing, it seems that the navigation is not happening. I've been testing with the following setup:
const routes: Routes = [
{ path: 'menu', loadChildren: () => import('./menu/menu.module').then(m => m.MenuPageModule) },//, canActivate: [MsalGuard]},
{ path: 'login', loadChildren: () => import('./login/login.module').then(m => m.LoginPageModule)},
{ path: '**', component: AuthComponent }
];@NgModule({ imports: [ RouterModule.forRoot(routes, { // useHash: true, // initialNavigation: 'disabled', onSameUrlNavigation: 'reload', }) ], exports: [RouterModule] }) export class AppRoutingModule { }
- Msal configuration:auth: {
clientId: environment.AZURE_CLIENT_ID,
authority: https://login.microsoftonline.com/${environment.AZURE_TENANT_ID},
redirectUri: 'http://localhost/auth',
postLogoutRedirectUri: '/',
}
- Redirect URI's in Azure portal:
So, given that my wildcard route is linked to my AuthComponent (where I'm not handling the response, I'm just trying to get to that component initially), I'm never navigated to my AuthComponent. I don't see any logging relating to navigation. I just get the timeout, and the following in the network tab of (Edge) Devtools:
I think I found the root cause. I increased the timeout duration of the iFrame, and inspected it. There, I can see the following error The webpage at http://localhost/auth#code=... could not be loaded because: net::ERR_CONNECTION_REFUSED.
Is there a "different" way where I can get the hash response? If I have that, I can process it with handleRedirectPromise.
Or, what is currently working, when I perform the following:
var request: SilentRequest = {
scopes: [`${environment.AZURE_CLIENT_ID}/.default`],
cacheLookupPolicy: CacheLookupPolicy.Default,
account: account
};
this.msalService.instance.acquireTokenSilent(request)
.then((result) => {
console.log("AUTH_SERVICE | ACQUIRE_TOKEN_SILENT:SUCCESS - Result", result);
})
.catch((e) => {
console.log("AUTH_SERVICE (ACQUIRE_TOKEN_SILENT) | Error = ", e)
});CacheLookupPolicy.Default is documented as follows: acquireTokenSilent will attempt to retrieve an access token from the cache. If the access token is expired or cannot be found the refresh token will be used to acquire a new one. Finally, if the refresh token is expired, acquireTokenSilent will attempt to silently acquire a new access token, id token, and refresh token.
Suppose the user hasn't used the APP in 24+ hours (but was previously logged in), if I pass the account (which contains a login_hint), will acquireTokenSilent be able to acquire new tokens (without creating an iFrame)? Because that's what I need: for my user not to log in again after 24+ hours.
tnorling
commented
8 months ago Is there a "different" way where I can get the hash response? If I have that, I can process it with handleRedirectPromise.
No and even if you could, handleRedirectPromise will only process hash responses for redirect requests.
Suppose the user hasn't used the APP in 24+ hours (but was previously logged in), if I pass the account (which contains a login_hint), will acquireTokenSilent be able to acquire new tokens (without creating an iFrame)? Because that's what I need: for my user not to log in again after 24+ hours.
No, an iframe is the only way to silently get new tokens silently when the refresh token has expired.
There, I can see the following error The webpage at http://localhost/auth#code=... could not be loaded because: net::ERR_CONNECTION_REFUSED.
You need to figure out why your app is refusing connections to your /auth route, that's the only way you're going to get this to work.
microsoft-github-policy-service[bot]
commented
8 months ago @kevveh This issue has been automatically marked as stale because it is marked as requiring author feedback but has not had any activity for 5 days. If your issue has been resolved please let us know by closing the issue. If your issue has not been resolved please leave a comment to keep this open. It will be closed automatically in 7 days if it remains stale.
Core Library
MSAL.js (@azure/msal-browser)
Core Library Version
3.7.1
Wrapper Library
MSAL Angular (@azure/msal-angular)
Wrapper Library Version
3.0.11
Public or Confidential Client?
Public
Description
I inherited an Angular Ionic application, designed to run on Android. Originally, this application used MSADAL to authenticate.
After this was deprecated, I switched to MSAL. The problem we are facing now, since the application is developed as a web application, is that the users (sometimes) have to log in multiple times a day (because the application needs to be registered as an SPA, and SPA refresh tokens are only valid for 24h).
This is not an ideal scenario. So, I'm currently trying to renew the tokens in the background if possible. At first I tried this with aqcuireTokenSilent, but I kept getting the following error: 'monitor_window_timeout: Token acquisition in iframe failed due to timeout.'
I've tried switching to ssoSilent, but I het the same error ('monitor_window_timeout: Token acquisition in iframe failed due to timeout.')
A regular login via redirect does work.
I've tried debugging via Devtools on Edge, and I can see the following request (if needed I can provide a screenshot):
So, based on this, It seems I am getting a response, but it's not processing.
Error Message
'monitor_window_timeout: Token acquisition in iframe failed due to timeout. For more visit: aka.ms/msaljs/browser-errors'
MSAL Logs
[Thu, 01 Feb 2024 13:28:28 GMT] : [] : @azure/msal-browser@3.7.1 : Trace - BrowserCacheManager.getActiveAccount: Active account filters schema found [Thu, 01 Feb 2024 13:28:28 GMT] : [] : @azure/msal-browser@3.7.1 : Trace - BrowserCacheManager.getAccountKeys called [Thu, 01 Feb 2024 13:28:28 GMT] : [] : @azure/msal-browser@3.7.1 : Trace - BrowserCacheManager.getAccount called [Thu, 01 Feb 2024 13:28:28 GMT] : [] : @azure/msal-browser@3.7.1 : Trace - BrowserCacheManager.getTokenKeys called [Thu, 01 Feb 2024 13:28:28 GMT] : [] : @azure/msal-common@14.6.1 : Trace - CacheManager - getIdToken called [Thu, 01 Feb 2024 13:28:28 GMT] : [] : @azure/msal-browser@3.7.1 : Trace - BrowserCacheManager.getIdTokenCredential: cache hit [Thu, 01 Feb 2024 13:28:28 GMT] : [] : @azure/msal-common@14.6.1 : Trace - getAliasesFromMetadata called with source: config [Thu, 01 Feb 2024 13:28:28 GMT] : [] : @azure/msal-common@14.6.1 : Trace - getAliasesFromMetadata called with source: hardcoded_values [Thu, 01 Feb 2024 13:28:28 GMT] : [] : @azure/msal-common@14.6.1 : Trace - getAliasesFromMetadata: found cloud discovery metadata in hardcoded_values, returning aliases [Thu, 01 Feb 2024 13:28:28 GMT] : [] : @azure/msal-common@14.6.1 : Info - CacheManager:getIdToken - Returning ID token [Thu, 01 Feb 2024 13:28:28 GMT] : [] : @azure/msal-browser@3.7.1 : Verbose - preflightBrowserEnvironmentCheck started [Thu, 01 Feb 2024 13:28:28 GMT] : [b19977ca-caf6-4e0f-b63e-2e8d22460626] : @azure/msal-browser@3.7.1 : Verbose - ssoSilent called [Thu, 01 Feb 2024 13:28:28 GMT] : [] : @azure/msal-browser@3.7.1 : Info - Emitting event: msal:ssoSilentStart [Thu, 01 Feb 2024 13:28:28 GMT] : [] : @azure/msal-browser@3.7.1 : Verbose - Emitting event to callback d08a493c-9f19-4ee1-8292-1cca81b5e304: msal:ssoSilentStart [Thu, 01 Feb 2024 13:28:28 GMT] : [] : @azure/msal-angular@3.0.11 : Verbose - BroadcastService - msal:ssoSilentStart results in setting inProgress from none to ssoSilent [Thu, 01 Feb 2024 13:28:28 GMT] : [] : @azure/msal-browser@3.7.1 : Trace - canUseNative called [Thu, 01 Feb 2024 13:28:28 GMT] : [] : @azure/msal-browser@3.7.1 : Trace - isNativeAvailable called [Thu, 01 Feb 2024 13:28:28 GMT] : [] : @azure/msal-browser@3.7.1 : Trace - isNativeAvailable: allowNativeBroker is not enabled, returning false [Thu, 01 Feb 2024 13:28:28 GMT] : [] : @azure/msal-browser@3.7.1 : Trace - canUseNative: isNativeAvailable returned false, returning false [Thu, 01 Feb 2024 13:28:28 GMT] : [] : @azure/msal-browser@3.7.1 : Trace - BrowserCacheManager.getAuthorityMetadata: cache hit [Thu, 01 Feb 2024 13:28:28 GMT] : [] : @azure/msal-browser@3.7.1 : Trace - BrowserCacheManager.setAuthorityMetadata called [Thu, 01 Feb 2024 13:28:28 GMT] : [b19977ca-caf6-4e0f-b63e-2e8d22460626] : @azure/msal-common@14.6.1 : Trace - Executing function authClientCreateQueryString [Thu, 01 Feb 2024 13:28:28 GMT] : [b19977ca-caf6-4e0f-b63e-2e8d22460626] : @azure/msal-common@14.6.1 : Verbose - createAuthCodeUrlQueryString: login_hint claim present on account [Thu, 01 Feb 2024 13:28:28 GMT] : [b19977ca-caf6-4e0f-b63e-2e8d22460626] : @azure/msal-common@14.6.1 : Trace - Returning result from authClientCreateQueryString [Thu, 01 Feb 2024 13:28:38 GMT] : [] : @azure/msal-browser@3.7.1 : Trace - BrowserCacheManager.getServerTelemetry: cache hit [Thu, 01 Feb 2024 13:28:38 GMT] : [] : @azure/msal-browser@3.7.1 : Trace - BrowserCacheManager.setServerTelemetry called [Thu, 01 Feb 2024 13:28:38 GMT] : [] : @azure/msal-browser@3.7.1 : Info - Emitting event: msal:ssoSilentFailure [Thu, 01 Feb 2024 13:28:38 GMT] : [] : @azure/msal-browser@3.7.1 : Verbose - Emitting event to callback d08a493c-9f19-4ee1-8292-1cca81b5e304: msal:ssoSilentFailure [Thu, 01 Feb 2024 13:28:38 GMT] : [] : @azure/msal-angular@3.0.11 : Verbose - BroadcastService - msal:ssoSilentFailure results in setting inProgress from ssoSilent to none [Thu, 01 Feb 2024 13:28:38 GMT] : [] : @azure/msal-browser@3.7.1 : Trace - BrowserCacheManager.getActiveAccount: Active account filters schema found [Thu, 01 Feb 2024 13:28:38 GMT] : [] : @azure/msal-browser@3.7.1 : Trace - BrowserCacheManager.getAccountKeys called [Thu, 01 Feb 2024 13:28:38 GMT] : [] : @azure/msal-browser@3.7.1 : Trace - BrowserCacheManager.getAccount called [Thu, 01 Feb 2024 13:28:38 GMT] : [] : @azure/msal-browser@3.7.1 : Trace - BrowserCacheManager.getTokenKeys called [Thu, 01 Feb 2024 13:28:38 GMT] : [] : @azure/msal-common@14.6.1 : Trace - CacheManager - getIdToken called [Thu, 01 Feb 2024 13:28:38 GMT] : [] : @azure/msal-browser@3.7.1 : Trace - BrowserCacheManager.getIdTokenCredential: cache hit [Thu, 01 Feb 2024 13:28:38 GMT] : [] : @azure/msal-common@14.6.1 : Trace - getAliasesFromMetadata called with source: config [Thu, 01 Feb 2024 13:28:38 GMT] : [] : @azure/msal-common@14.6.1 : Trace - getAliasesFromMetadata called with source: hardcoded_values [Thu, 01 Feb 2024 13:28:38 GMT] : [] : @azure/msal-common@14.6.1 : Trace - getAliasesFromMetadata: found cloud discovery metadata in hardcoded_values, returning aliases [Thu, 01 Feb 2024 13:28:38 GMT] : [] : @azure/msal-common@14.6.1 : Info - CacheManager:getIdToken - Returning ID token [Thu, 01 Feb 2024 13:28:38 GMT] : [] : @azure/msal-browser@3.7.1 : Trace - BrowserCacheManager.getActiveAccount: Active account filters schema found [Thu, 01 Feb 2024 13:28:38 GMT] : [] : @azure/msal-browser@3.7.1 : Trace - BrowserCacheManager.getAccountKeys called [Thu, 01 Feb 2024 13:28:38 GMT] : [] : @azure/msal-browser@3.7.1 : Trace - BrowserCacheManager.getAccount called [Thu, 01 Feb 2024 13:28:38 GMT] : [] : @azure/msal-browser@3.7.1 : Trace - BrowserCacheManager.getTokenKeys called [Thu, 01 Feb 2024 13:28:38 GMT] : [] : @azure/msal-common@14.6.1 : Trace - CacheManager - getIdToken called [Thu, 01 Feb 2024 13:28:38 GMT] : [] : @azure/msal-browser@3.7.1 : Trace - BrowserCacheManager.getIdTokenCredential: cache hit [Thu, 01 Feb 2024 13:28:38 GMT] : [] : @azure/msal-common@14.6.1 : Trace - getAliasesFromMetadata called with source: config [Thu, 01 Feb 2024 13:28:38 GMT] : [] : @azure/msal-common@14.6.1 : Trace - getAliasesFromMetadata called with source: hardcoded_values [Thu, 01 Feb 2024 13:28:38 GMT] : [] : @azure/msal-common@14.6.1 : Trace - getAliasesFromMetadata: found cloud discovery metadata in hardcoded_values, returning aliases [Thu, 01 Feb 2024 13:28:38 GMT] : [] : @azure/msal-common@14.6.1 : Info - CacheManager:getIdToken - Returning ID token
Network Trace (Preferrably Fiddler)
MSAL Configuration
Relevant Code Snippets
Reproduction Steps
Expected Behavior
A successfull response from ssoSilent ("AUTH_SERVICE | ACQUIRE_TOKEN_SSOSILENT:SUCCESS" is shown in the logs).
Identity Provider
Entra ID (formerly Azure AD) / MSA
Browsers Affected (Select all that apply)
Other
Regression
No response
Source
External (Customer)