microsoft-authentication-library-for-js: acquireTokenSilent times out with X-Frame-Error when signing in with MFA enabled B2C policy

Similar issue to #699 and #1088 that is manifested when signing in to an app using Multi Factor Authentication in B2C.

I’m submitting a…

[ ] Regression (a behavior that used to work and stopped working in a new release)
[X] Bug report 
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Other... Please describe:


  • Firefox version XX
  • Chrome version 79.0.3945.79
  • IE version XX
  • Edge version 80.0.355.1
  • Safari version XX

Library version

Library version: 1.1.3 and 1.2.0

Current behavior

When signing in through an MFA-enabled AAD B2C policy, acquireTokenSilent() hangs for a few seconds and throws the following errors:

  • Refused to display '' in a frame because it set 'X-Frame-Options' to 'deny'.
  • ClientAuthError: Token renewal operation failed due to timeout.

It works if we are using acquireTokenPopup(), but not desired since user has already performed MFA.

Expected behavior

Since the user has already performed interactive MFA via B2C during sign-in, it is expected that acquireTokenSilent() should be able to get a token just as it does when not using MFA.

Minimal reproduction of the problem with instructions

The quickest way to reproduce the issue is to use and use a MFA-enabled B2C Policy.

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 16 (5 by maintainers)

Most upvoted comments

Hi everyone, I’m curious if this extends beyond MFA and into custom policies in general. We employ an Azure B2C custom policy for “forgot password” in addition to two other proprietary experiences - in any of these three scenarios we are unable to use acquireTokenSilent() to obtain an access token after a successful interactive flow for the initial ID token.

When I would expect acquireTokenSilent() to ultimately cause Azure B2C to respond with a 302 status and redirect to our registered URI, it’s returning a 200 status instead, with what appears to be the original interactive policy form instead (and fails to load in the browser due to the IFRAME-blocking header).

Two additional notes:

  • The issue only occurs on implicit flows; our companion native apps using auth code flow are able to obtain access tokens with these policies.
  • This is not an issue with the standard policies (login or sign up, for example).

@derisen related to the other issue I tagged you in.