Microsoft-authentication-library-for-js: Refused to display in a frame because it set 'X-Frame-Options' to 'deny'.

[thdotnet]

Hi,

I've cloned this repository and changed the settings to my Azure AD B2C. It opens the popup but it seems that during the process of acquiring the token, it's raising the error:

Refused to display 'https://login.microsoftonline.com/te/x.onmicrosoft.com/b2c_1_jms-su-si/oauth2/v2.0/authorize?response_type=token&scope=https%3A%2F%2Fx.onmicrosoft.com%2Fdemoapi%2Fdemo.read%20openid%20profile&client_id=d4ea3a10-bf58-43c7-9a0d-189a1cacee07&redirect_uri=http%3A%2F%2Flocalhost%3A62592%2F&state=b500b7af-6aee-4d32-8e34-5ec1ead1fa84&nonce=41fff769-56e9-41cf-a559-778dc10026e4&client_info=1&x-client-SKU=MSAL.JS&x-client-Ver=0.1.1&client-request-id=ea9d0c0b-38fd-49cc-921e-4e21176aaede&prompt=none&domain_req=534fe24d-0068-4fe9-84a2-7872f971da75&login_req=0f09664c-2e62-48c2-b26c-adc5acf9debf-b2c_1_jms-su-si&domain_hint=organizations' in a frame because it set 'X-Frame-Options' to 'deny'.

Is that because Chrome updated it's settings or it's a wrong configuration on my side?

[thdotnet]

I've replaced the scope with the GUID and it's working now.

[ritwbanerjee]

can you give a code snippet on how you have replaces the scope with GUID

[ashpr]

For anyone else struggling with this...

This iframe is often produced from the url itself producing an error. In my case it was navigating back to my SPA from another url ie. myapp.com/some/other/path, you still need to hard-set your redirectUri to myapp.com.

[blinkybill]

@ashpr Did you mean your page that's calling msal.js login functionality was at "myapp.com/some/other/path", but that you needed to set the redirectUri in Azure portal to be your root domain "myapp.com" only?

[ashpr]

@blinkybill It's the redirectUri in your msal configuration because by default if you don't provide a redirectUri, it defaults to window.location.href which will include the /path/.

it needs to match the uris on your Azure portal, which in our case was myapp.com but we had users bookmarking the app on myapp.com/something and getting logged out/white screened.

[bojantv]

Just in case it helps someone or maybe someone can correct me:
I had issues with this when changing authority like when using loginRedirect() to trigger edit_profile or reset_password flows. When coming back to starting page the cached (localStorage) access token and idToken had wrong authority values and that caused the access token not beeing fetched with the error like in the title. I resolved it by clearing those wrong values from localStorage... Hackintosh way.
I would like for someone to set me back on the right path.

[ashpr]

Just in case it helps someone or maybe someone can correct me:
I had issues with this when changing authority like when using loginRedirect() to trigger edit_profile or reset_password flows. When coming back to starting page the cached (localStorage) access token and idToken had wrong authority values and that caused the access token not beeing fetched with the error like in the title. I resolved it by clearing those wrong values from localStorage... Hackintosh way.
I would like for someone to set me back on the right path.

We had a similar issue, and the answer was not to change your current UserAgentApplication authority, but instead create a new UserAgentApplication with the new authority.

[bojantv]

Just in case it helps someone or maybe someone can correct me:
I had issues with this when changing authority like when using loginRedirect() to trigger edit_profile or reset_password flows. When coming back to starting page the cached (localStorage) access token and idToken had wrong authority values and that caused the access token not beeing fetched with the error like in the title. I resolved it by clearing those wrong values from localStorage... Hackintosh way.
I would like for someone to set me back on the right path.

We had a similar issue, and the answer was not to change your current UserAgentApplication authority, but instead create a new UserAgentApplication with the new authority.

Thank you for this. Actually I had a dream this night to try creating a new instance for edit profile and reset the password :).
I actually started coding and separating different stuff in different components this morning.
One thing I think might help (or even is mandatory) is changing storage for the other instance, but then again having written that maybe the session ID might be enough for msal to differentiate between the two different UserAgentApplication instances in the same storage type.
Also maybe I'll need different redirect pages for login stuff vs edit profile vs reset password, just to supply a different redirect handler because of the mentioned session ID, or maybe I won't again.
Trial and error to win this game. I appreciate the response again, it did shed some light and encouraged me to try the mentioned approach, Thanks!

[ashpr]

Just in case it helps someone or maybe someone can correct me:
I had issues with this when changing authority like when using loginRedirect() to trigger edit_profile or reset_password flows. When coming back to starting page the cached (localStorage) access token and idToken had wrong authority values and that caused the access token not beeing fetched with the error like in the title. I resolved it by clearing those wrong values from localStorage... Hackintosh way.
I would like for someone to set me back on the right path.

We had a similar issue, and the answer was not to change your current UserAgentApplication authority, but instead create a new UserAgentApplication with the new authority.

Thank you for this. Actually I had a dream this night to try creating a new instance for edit profile and reset the password :).
I actually started coding and separating different stuff in different components this morning.
One thing I think might help (or even is mandatory) is changing storage for the other instance, but then again having written that maybe the session ID might be enough for msal to differentiate between the two different UserAgentApplication instances in the same storage type.
Also maybe I'll need different redirect pages for login stuff vs edit profile vs reset password, just to supply a different redirect handler because of the mentioned session ID, or maybe I won't again.
Trial and error to win this game. I appreciate the response again, it did shed some light and encouraged me to try the mentioned approach, Thanks!

Here's the code we use for the password reset application.

import { UserAgentApplication } from 'msal';
import { ADB2C_CLIENT_ID, ADB2C_PASSWORD_RESET_AUTHORITY } from '../constants';
import { HubMsalConfig } from '../msal-config'; // Our default MSAL Config.

export const msalPasswordChangeApplication = new UserAgentApplication(
      ADB2C_CLIENT_ID,
      ADB2C_PASSWORD_RESET_AUTHORITY,
      () => {},
      {
        validateAuthority: false,
        redirectUri: HubMsalConfig.redirectUri
      })
);

Using it:

    msalPasswordResetApplication.loginRedirect(ADB2C_SCOPES);

I know what you mean, its been a bumpy ride for us but we're finally there. I've been meaning to blog about all this at some point as I feel the documentation really is lacking.

[bojantv]

Just in case it helps someone or maybe someone can correct me:
I had issues with this when changing authority like when using loginRedirect() to trigger edit_profile or reset_password flows. When coming back to starting page the cached (localStorage) access token and idToken had wrong authority values and that caused the access token not beeing fetched with the error like in the title. I resolved it by clearing those wrong values from localStorage... Hackintosh way.
I would like for someone to set me back on the right path.

We had a similar issue, and the answer was not to change your current UserAgentApplication authority, but instead create a new UserAgentApplication with the new authority.

Thank you for this. Actually I had a dream this night to try creating a new instance for edit profile and reset the password :).
I actually started coding and separating different stuff in different components this morning.
One thing I think might help (or even is mandatory) is changing storage for the other instance, but then again having written that maybe the session ID might be enough for msal to differentiate between the two different UserAgentApplication instances in the same storage type.
Also maybe I'll need different redirect pages for login stuff vs edit profile vs reset password, just to supply a different redirect handler because of the mentioned session ID, or maybe I won't again.
Trial and error to win this game. I appreciate the response again, it did shed some light and encouraged me to try the mentioned approach, Thanks!

Here's the code we use for the password reset application.

import { UserAgentApplication } from 'msal';
import { ADB2C_CLIENT_ID, ADB2C_PASSWORD_RESET_AUTHORITY } from '../constants';
import { HubMsalConfig } from '../msal-config'; // Our default MSAL Config.

export const msalPasswordChangeApplication = new UserAgentApplication(
      ADB2C_CLIENT_ID,
      ADB2C_PASSWORD_RESET_AUTHORITY,
      () => {},
      {
        validateAuthority: false,
        redirectUri: HubMsalConfig.redirectUri
      })
);

Using it:

    msalPasswordResetApplication.loginRedirect(ADB2C_SCOPES);

I know what you mean, its been a bumpy ride for us but we're finally there. I've been meaning to blog about all this at some point as I feel the documentation really is lacking.

Thanks for your code. However, I can see that you're using <=0.2.4 version, I am trying to set up using 1.2.0 version. I seems to be even bumpier now :). Your redirect callback is empty, I am trying to handle successful and unsuccessful returns and cover also cancel and hopefully not logOut the user after changing password just update all one the fly. And do the same for edit profile.
A blog is a great ides, I planned on spending 1-2 days tops on this, and after 3 it's still in progress. I tried various react libraries and opted out to do my own msal integration yet still issues. THANKS