Managing external identities to enable secure access for partners, customers, and other non-employees
Hi Lisa — it sounds like you’re hitting the block_iframe_reload issue when MSAL.js calls acquireTokenSilent for Microsoft Entra External ID, and the response ends up triggering a redirect/302 flow inside MSAL’s hidden iframe.
Even after using the documented workaround (setting a separate redirect URI), there are a couple other things you can double-check based on what Microsoft documents about how MSAL.js handles silent renew/redirects in iframes.
What causes this (quick recap)
MSAL.js uses a hidden iframe for silent token acquisition/renewal. When Entra returns the response to the configured redirect_uri, the browser loads the HTML at that redirect URI inside the iframe due to the 302 redirect, which can lead to:
- the app “reloading” (especially if the redirect URI points to your app root),
- nested iframe behavior,
- or errors if the redirected page isn’t safe to load in an iframe context.
MSAL can’t “dismiss” the 302 because it must process the redirect to get the token—so the mitigation is all about what page is used for the iframe redirect.
What you can do besides “add a redirect URI to a different page”
1) Make sure the iframe redirect URI points to a simple page that does not require authentication
Per Microsoft guidance, configure the redirect_uri in the MSAL.js config to a simple HTML page that:
- does not trigger sign-in / authentication flows,
- does not depend on protected routing,
- and is suitable to be loaded in an iframe.
This is the recommended workaround specifically for avoiding iframe reloads and nested-auth/iframe issues.
Key point: it’s not just “a different page”—it should be a page that doesn’t itself require authentication.
2) Ensure the iframe redirect URI matches what’s registered in Entra admin center
Microsoft’s guidance calls out that the redirect URI you use in MSAL must match the redirect_uri registered in the Entra app registration.
So it’s worth confirming there’s no mismatch in:
- exact path,
- trailing slash differences,
- environment differences (dev/stage/prod),
- or multiple redirect URIs where MSAL might be selecting the “wrong” one for a given flow.
3) If your app initializes globally, avoid running full app initialization during iframe loads
MSAL also recommends an application-level pattern: conditionally avoid loading the parts of your SPA that cause reloads when the app is running inside an iframe.
If your React app has a “root” initialization that always boots routing/auth logic, you can adopt the same idea as the MSAL doc’s example (Angular), e.g. render minimal shell / skip expensive initialization when detected as iframe context—so that when the redirect URI page loads inside the iframe, the rest of your app doesn’t re-trigger.
(Exact React implementation depends on your routing/bootstrap setup, but the concept is the same.)
Reference list (all relevant docs used above)
- Avoid page reloads when acquiring and renewing tokens silently using MSAL.js https://learn.microsoft.com/entra/identity-platform/msal-js-avoid-page-reloads
-
blockIframeReload/ BrowserAuthErrorCodes ("block_iframe_reload") https://learn.microsoft.com/javascript/api/@azure/msal-browser/browserautherrorcodes?view=msal-js-latest - BrowserUtils
blockReloadInHiddenIframes()(function details) https://learn.microsoft.com/javascript/api/@azure/msal-browser/browserutils?view=msal-js-latest - Resolve Microsoft Entra sign-in or access management issues (recommended support entry point) https://supportabilityhub.microsoft.com/solutions/apollosolutions/16479a8b-b67c-66f8-d7c3-c9a85f7797d0/apollo-f6b88fe7-454b-4e8a-903f-c7026b8ff85d