Share via

block_iframe_reload excpetion when recieving authentication repsonse

Lisa 60 Reputation points
2026-06-05T07:42:10.97+00:00

Hello,

We have a React application that is refreshing a session with Microsoft Entra External. We are calling acquire token silent endpoint. We have already done the suggestions in the article (https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/docs/errors.md#block_iframe_reload) of adding a redirect URI to a different page. Is there anything else we can do to address this?

Many thanks,

Lisa

Microsoft Security | Microsoft Entra | Microsoft Entra External ID

1 answer

Sort by: Most helpful
  1. Shubham Sharma 17,755 Reputation points Microsoft External Staff Moderator
    2026-06-05T08:05:40.5+00:00

    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)

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.