Microsoft-authentication-library-for-js: Identity Provider Google: Refused to display 'https://accounts.google.com' in a frame because it set 'X-Frame-Options' to 'sameorigin'.

Created on 2 Sep 2019  Â·  21Comments  Â·  Source: AzureAD/microsoft-authentication-library-for-js

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
[X] Documentation issue or request
[ ] Other... Please describe:

Browser:

  • [X] Chrome version 76.0.3809
  • [ ] Firefox version
  • [ ] IE version
  • [ ] Edge version
  • [ ] Safari version

Library version


Library version: 1.1.3

Current behavior

Using third party identity provider, like Google is not possible within MSAL for js. Google responses with header set to ´x-frame-options: SAMEORIGIN`. MSAL cannot load the iframe and access to the identity data.

This issue was already reported here but the corresponded issue and stackoverflow question remains unanswered.

Expected behavior


MSAL should support third party identity providers from Azure (Google, Twitter, LinkedIn, etc)

Any suggestions, or official statement regarding usage of third party B2C identity providers in azure with this library, which seems to be an official way to integrate with Azure Active Directory?

Minimal reproduction of the problem with instructions

Configure B2C tenant and use https://github.com/Azure-Samples/active-directory-b2c-javascript-msal-singlepageapp example (btw outdated link to msal library)

b2c bug more-information-needed

Most helpful comment

My take so far:

  • Google accounts are accessible with B2C with our current sample here - the existing issue is only with multiple google accounts, and it is a bug with the B2C Service. When there are two active google accounts logged in, msal js sends prompt=select_account to the service for the user to be able to select the appropriate account but the B2C service is swallowing that. It is in their pipeline to address this issue. cc @ktsakas.

  • response_type is set by the library and not by the user by design. If a user is logging in for the first time, we set it to id_token; based on the cache state and any hint sent to us about an existing session, we set it to id_token_token. We advise the users not to modify this, as this may cause performance issues fetching two tokens for all use cases, even in cases you don't need to. It also may cause issues in older browsers like IE which is tracked with #1172

  • The reason why this workaround seemed to work in some use cases is that it is tying up the id_token and token for a given call but for the reasons mentioned above and the lack of support code around, I am unsure if this works in all scenarios.

I will have our b2c dev take a look at this sameorigin bug again and will update when we have more info.

All 21 comments

@ktsakas FYI.

I was able to make it working locally by modifying one line in UserAgentApplication:

//const responseType = isLoginCall ? ResponseTypes.id_token : this.getTokenType(account, scopes, false);
const responseType = ResponseTypes.id_token_token; 

ResponseTypes.id_token_token does the trick, thanks to @sushi4u for the hint here

is it possible to specify the default response type via configuration?

any comment from maintainers?

Hi Andre,

I can't see your message anymore. did you found the code place to tweak?

Best regards,

Nikolai

Am Sa., 7. Sept. 2019 um 13:50 Uhr schrieb André Naumann <
[email protected]>:

@kumarunster https://github.com/kumarunster that's not working for me
when writing the following because loginRedirect is not returning a promise
(at least my console says so):

this.msalInstance.loginRedirect().then((loginResponse) => {
this.AcquireToken(); // my function that tries to acquire a token
resolve(loginResponse);
}).catch((error) => {
console.error(error);
reject(error);
});

Could you provide me your code how do you call the loginRedirect or even
share your msal.js? That would be great!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/965?email_source=notifications&email_token=AAQB35BIUF4ASQ4GT5Z2EW3QIOIPJA5CNFSM4IS6ZVFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6EXCTI#issuecomment-529101133,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAQB35FWRP7ITXADCMWCH6LQIOIPJANCNFSM4IS6ZVFA
.

Hi Nikolai,

yes. Meny thanks for your help. I forked the repo and fixed it.

Cheers

Am Mo., 9. Sept. 2019 um 13:25 Uhr schrieb Nikolai Raitsev <
[email protected]>:

Hi Andre,

I can't see your message anymore. did you found the code place to tweak?

Best regards,

Nikolai

Am Sa., 7. Sept. 2019 um 13:50 Uhr schrieb André Naumann <
[email protected]>:

@kumarunster https://github.com/kumarunster that's not working for me
when writing the following because loginRedirect is not returning a
promise
(at least my console says so):

this.msalInstance.loginRedirect().then((loginResponse) => {
this.AcquireToken(); // my function that tries to acquire a token
resolve(loginResponse);
}).catch((error) => {
console.error(error);
reject(error);
});

Could you provide me your code how do you call the loginRedirect or even
share your msal.js? That would be great!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<
https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/965?email_source=notifications&email_token=AAQB35BIUF4ASQ4GT5Z2EW3QIOIPJA5CNFSM4IS6ZVFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6EXCTI#issuecomment-529101133
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AAQB35FWRP7ITXADCMWCH6LQIOIPJANCNFSM4IS6ZVFA

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/965?email_source=notifications&email_token=ABIZSWLYWFQFSQI75FZDERDQIYXBFA5CNFSM4IS6ZVFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6HGNAY#issuecomment-529426051,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABIZSWNJPX2QYLL3DWCSVFDQIYXBFANCNFSM4IS6ZVFA
.

@kumarunster Can you share us the sample to repro this? We are curious why editing the response_type is solving this issue.

@sameerag sorry, I cannot provide an easy to go reproducer, because it requries setup on google and azure. But for me is clear, why response_type set to id_token_token solves the issue: it is because the tokens are retrieved in one call.

I am still getting this issue and it is unclear how to resolve it/work around it. Any suggestions?

@WretchedDade did you checked the workaround i posted a while ago?

@WretchedDade according to the workaround of @kumarunster I did the following:
image

Hope that helps

@kumarunster @sk2andy is there no way to resolve this without modifying the source code?

@kumarunster Can you please test this with [email protected] without the tweak and let us know if the bug still exists?

@sameerag thanks for your comment, could you please point us to some release notes or commit that fixes that issue? I believe that @WretchedDade is already on [email protected], isn't?

@kumarunster is correct, I am already using [email protected] without the tweak.

The same happens to me with my google login at our site. It doesn't even help to clear the local storage (of "my site"), in an anonymous / private window it works though... very very strange.

Version: 1.2.0

edit:
is this fixed in https://github.com/AzureAD/microsoft-authentication-library-for-js/releases/tag/v1.2.1 one of the bugs kind of seems relatable.... I can "soonish" try to upgrade to this version...

edit2:
Nope just upgraded and it's still happening.

@sameerag Any update?

My take so far:

  • Google accounts are accessible with B2C with our current sample here - the existing issue is only with multiple google accounts, and it is a bug with the B2C Service. When there are two active google accounts logged in, msal js sends prompt=select_account to the service for the user to be able to select the appropriate account but the B2C service is swallowing that. It is in their pipeline to address this issue. cc @ktsakas.

  • response_type is set by the library and not by the user by design. If a user is logging in for the first time, we set it to id_token; based on the cache state and any hint sent to us about an existing session, we set it to id_token_token. We advise the users not to modify this, as this may cause performance issues fetching two tokens for all use cases, even in cases you don't need to. It also may cause issues in older browsers like IE which is tracked with #1172

  • The reason why this workaround seemed to work in some use cases is that it is tying up the id_token and token for a given call but for the reasons mentioned above and the lack of support code around, I am unsure if this works in all scenarios.

I will have our b2c dev take a look at this sameorigin bug again and will update when we have more info.

@sameerag thanks for the follow up. I am signed in to multiple google accounts. I'll log out of all but one and see if that resolves my issue!

Any update @WretchedDade?
@ktsakas Can we debug this sometime?

I can confirm my issue is related to multiple google accounts being signed in.

Great! Thanks @WretchedDade, As mentioned, this is work-in-progress with B2C service tracked with #842. Can I close this issue?

Closing this. Please track the original issue with #842.

Was this page helpful?
0 / 5 - 0 ratings