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'.

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:

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)

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 1
Comments: 21 (7 by maintainers)

Most upvoted comments

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 on Jan 30, 2020