I’m working on an Angular 18 app that connects to .NET 8 backend APIs. The backend is deployed in three regions (Americas, Europe, Asia Pacific) with their own Azure SQL databases for data compliance.
My frontend only runs in Europe but needs to call backends in all three regions. Everything is registered in Azure AD using OpenID Connect auth flow.
Here’s my frontend config setup:
var appSettings = {
tenantId: 'mycompany.onmicrosoft.com',
appId: '<Frontend App Registration ID>',
apiScopes: ['<Europe API ID>', '<Americas API ID>', '<Asia API ID>'],
loginRedirect: window.location.href,
logoutRedirect: window.location.origin + '/home',
authEndpoint: 'https://login.microsoftonline.com/'
};
I have two modules in my app - one at root level and another as a virtual directory subsite. I’m using MSAL Angular v3.0.23 and MSAL Browser v2.39.0.
Originally I used SessionStorage for token caching but security testing flagged this as risky. When I switched to MemoryStorage, the app works fine with the Europe backend but fails with other regions showing this error:
BrowserAuthError: no_account_error: No account object provided to acquireTokenSilent and no active account has been set. Please call setActiveAccount or provide an account on the request.
The error happens during silent token acquisition. How can I properly handle account management when using memory storage across different backend regions? Any working examples would be really helpful.
sounds like a caching issue with memory storage. try checking if your token requests for different regions are using the same cache key - memory storage might be overwriting tokens between regions. also make sure your acquireTokenSilent calls include the specific scopes for each backend region since you have multiple api scopes configured. might need to handle each region’s tokens seperately in memory
The issue stems from memory storage not persisting account information across different token acquisition calls, unlike session storage which maintains state. When switching to memory storage, you need to explicitly manage the active account state. After successful login, immediately call msalInstance.setActiveAccount(account) with the account object from the login response. For silent token acquisition across different regions, ensure you’re passing the account parameter in your acquireTokenSilent calls rather than relying on the active account. I encountered similar behavior when implementing multi-region authentication. The solution was to store the account identifier in a service and retrieve it before each silent token request. You can get the account using msalInstance.getAccountByHomeId() or msalInstance.getAllAccounts()[0] if you have a single user scenario. Consider implementing a token service that handles account management centrally, ensuring the same account context is used for all regional API calls. This approach maintains security while providing consistent authentication behavior across your multi-region setup.
hmm interesting setup! are you initializing msal differently for each region call? i’ve seen similar issues where the account context gets lost between different api requests. what happens if you try calling getAllAccounts() right before your silent token aquisition - do you see any accounts there? also curious about your interceptor setup - are you using the same msal interceptor config for all three regions?