Home›Support›English Support›[Resolved] SSO iframe fails across top-level domains due to blocked cookies in modern browsers
[Resolved] SSO iframe fails across top-level domains due to blocked cookies in modern browsers
This thread is resolved. Here is a description of the problem and solution.
Problem: You are trying to use WPML's SSO feature to automatically sign users in across two different top-level domains using the iframe-based login method. However, in Chrome, the browser blocks the authentication cookies, preventing the SSO iframe from signing the user in. The cookies are set with SameSite=None and Secure, but due to browser policies like Chrome’s Privacy Sandbox, third-party cookies are blocked by default. Solution: We have reviewed the possibility of moving away from iframe-based SSO to an alternative approach such as redirect-based SSO using secure login tokens. However, we have decided not to pursue this direction at this time. This decision aligns with our current priorities and product direction, and we have not observed a significant demand for this feature from other clients. Our roadmap may evolve based on user demand, so your feedback is valuable and noted for future consideration.
If this solution does not resolve your issue or seems outdated, we recommend checking related known issues at https://wpml.org/known-issues/, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If you still need assistance, please open a new support ticket at WPML support forum.
This is the technical support forum for WPML - the multilingual WordPress plugin.
Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.
Background of the issue:
I am trying to use WPML’s SSO feature to automatically sign users in across two different top-level domains using the iframe-based login method. I expected the user to be automatically signed in on the second domain after visiting the first, without needing to log in again.
Symptoms:
The SSO iframe fails to sign the user in. In Chrome (normal browsing mode), the browser blocks the authentication cookies. The developer tools show the message: "This attempt to set a cookie via Set-Cookie header was blocked due to user preference." Cookies are set with SameSite=None and Secure, but Chrome’s Privacy Sandbox and similar restrictions in other browsers are blocking third-party cookies by default.
Questions:
Is there a plan to move away from iframe-based SSO and implement an alternative approach such as redirect-based SSO using secure login tokens?
Please advise on any available workaround or roadmap for supporting authentication across separate domains under current browser policies.
Thank you for waiting. I've received feedback from the development team:
You're correct that Chrome and other modern browsers are increasingly blocking third-party cookies by default, which affects iframe-based SSO across different top-level domains. This is why the SSO iframe is currently failing to authenticate users—the browser is blocking the required authentication cookies.
At the moment, WPML does not have plans to move away from the iframe-based method, primarily due to the significant development effort involved and the potential security implications of alternative approaches like token-based redirects. That said, we're open to revisiting this if browser restrictions become more widespread or more users are affected.
For now, a workaround isn't available within WPML, but we’re keeping an eye on new browser features like the FedCM API, which may eventually help provide a more reliable solution without relying on third-party cookies.
We understand that supporting cross-domain SSO without third-party cookies is technically complex, but given the current browser landscape — with both Chrome and Firefox now blocking these cookies by default for many users — this is no longer a fringe issue. For anyone using WPML across separate top-level domains, the existing iframe-based approach is effectively broken in real-world usage.
We use WPML across a number of large government agencies, and this limitation has become a growing source of frustration for their teams. These are high-profile, security-conscious organizations that rely on stable multilingual support, and the broken login experience is increasingly seen as a blocker.
We appreciate that you're monitoring developments like FedCM, but in the meantime, the lack of a supported workaround puts us in a difficult position. WPML requires login to happen on a single domain, so users are left without a functional way to switch languages while remaining authenticated.
Thanks for your time. Given the impact this is having across multiple public-sector deployments, we’d strongly encourage your team to reconsider the priority of this issue.
Thank you again for sharing your feedback — we really appreciate your input and the thoughtful suggestion.
We’ve carefully reviewed the feature you proposed, and at this time, we’ve decided not to move forward in that direction. While we understand the potential value, it doesn’t align with our current priorities and product direction. Additionally, we haven’t received similar requests from other clients so far, which also influences our decision-making.
That said, our roadmap evolves based on user demand. If we start seeing more interest in this area from other clients, we’ll certainly revisit the idea. Your feedback is noted and will help inform those future evaluations.
Thanks again for your understanding and ongoing collaboration.
