Microsoft-authentication-library-for-js: aquireTokenSilent blocked by sandboxed iframe

[jasonnutter]

@exuviae Are you using Azure B2C?

[exuviae]

Yes this is azure B2C.

[sameerag]

@ktsakas Does B2C submit a "form" at any point in token retrieval for "silent" calls?

[exuviae]

the issue seems to be related to a response returned from b2c in that includes a hidden form, the auth code and a piece of javascript that submits the form. the form contains three hidden params, code, state, and session_state.

[gabriel-kohen-by]

This seems to break this sample app as well using v.1.2.0: https://github.com/Azure-Samples/active-directory-b2c-javascript-msal-singlepageapp/issues/43

[sameerag]

Thanks for bringing this to our notice. Next few weeks, I will work on the B2C samples with their dev team and will update the status regards to the new design on MSAL JS and the B2C compatibility. cc @ktsakas @mmacy

[dfbaskin]

Is the fix as simple as adding allow-forms to WindowUtils.ts?

ifr.setAttribute("sandbox", "allow-scripts allow-same-origin");

[sameerag]

I think so. I have met the B2C devs to ensure that there is nothing else needed from our end. Hopefully we will be able to close this soon.

[dfbaskin]

I just tried updating that line, rebuilding, and incorporating the new files into my project, and I no longer see that error (I can also log in again).

ifr.setAttribute("sandbox", "allow-scripts allow-same-origin allow-forms");

Thanks!

[sameerag]

Great! Once I make sure this is the only thing needed, will release a patch with this fix this week/next week.

[Fhyarnir]

I have found that the current solution for me is to revert to msal package version 1.1.2. At version 1.2.0 I got errors about "..token calls blocked in hidden iframes" (only when using tabs / routes in react webpage), though I was still able to retrieve api data. While at "1.2.0-beta.0" version I got the abovementioned errors with blocked script calls (ie. when trying to do simple console.log statements).

With [email protected] it seems everything works fine and that I get none of those errors.

For future reference though, where would one manually input the "ifr.setAttribute("sandbox", "allow-scripts allow-same-origin allow-forms");"? Especially when not coding with "iframes" myself (in top-level code)?

[sameerag]

@Fhyarnir You are not expected to set any of the sandboxing properties. We are working on adding "allow-forms" with the PR #1191.

In general, the app need not be concerned with the hidden iframe, it is an internal mechanism for msal js:

• MSAL loads a hidden iframe for a silent call with the url set to login.microsoftonline.com (or any authority passed in request) with the parameters for that specific request.
• When a token has been acquired, the iframe is redirected to the url set in redirectUri (which can be set during configuration or in a request), thus loading the home page of the app, if set as the redirectUri (briefly) inside the hidden iframe. The page should only load for a brief moment (as we just need to extract the url containing the hash from the iframe), but it can be long enough for parts of the application to load (before the iframe is removed).
• The block_token_requests error occurs if we detect that the application is attempting to acquire an access token (e.g. by calling acquireTokenSilent) immediately on page load while the application is loaded inside one of these hidden iframes. The library throws this error to prevent negative side effects from occurring (namely endlessly requesting access tokens). This can happen when the token acquisition logic is part of the application load, and the same page is set as the redirectUri
• We generally don't recommend calling acquireTokenSilent on page load, but if you do, one approach to prevent this is to not call acquireTokenSilent on page load in this scenario, or catch the error and let is silently fail.
• The recommended option is to set your redirectUri to a blank html, as detailed in the release notes which would help with performance by preventing to reload the application and the side effects resulting from it.

We recommend to move to [email protected] and with the above usage, you should be able to launch your application without the aforementioned hiccups.

Hope this helps.

cc @hamiltonha

[alex-mason-by]

I have tried this out and it does resolve our B2C custom policy federation issues when federating from B2C to an AAD tenant. However, if we federate to the AAD common endpoint the issue is still present. In fact I can use the same AAD tenant via a direct custom policy configuration and the common endpoint custom policy configuration and the behavior is different with the prior one working and the common endpoint not. Is there a workaround or something MSAL.js or B2C can do because it is much more desirable to have a common endpoint configuration in B2C than enumerating each AAD tenant.