Multisite: Multidomain Single Sign On

[paaljoachim]

This came up in the Slack multisite channel a few days ago.
​https://wordpress.slack.com/archives/C03BVB47S/p1645670322425659

It would be very helpful to have multidomain Single Sign On as an option through the Network -> Settings -> Settings. (Should probably be renamed to General so that we do not have a Settings Settings screen.)

Here is a plugin: ​https://wordpress.org/plugins/multisite-multidomain-single-sign-on/

[realloc]

Thanks for raising this. The frustration is fair. I looked at how core handles multisite auth today to see how close we already are and what this would actually take.

Subdomain networks already have SSO. The auth cookie is set on a wildcard domain (.example.com), and cookie names and HMAC salts are network-wide, so a cookie from one site already validates on another. The cryptography is not the blocker.

Cross-TLD SSO (example.com and example.org) is a different problem. Browsers will not let one cookie span two unrelated domains, so it cannot be a settings toggle. It needs a new redirect-based signed-token handshake (log in on A, bounce through B with a one-time token that B redeems to set its own cookie). That is a security-sensitive feature, not a flag. The main risks:

• Crossing separate trust zones. The salts are already shared, and the crypto already validates network-wide. Today separate TLDs are kept apart only by cookie scope (host-only cookies). Cross-TLD SSO removes that last isolation, so a session becomes valid across domains that are usually under separate control. This drops the network to the weakest independently administered domain: an XSS or rogue plugin there is now good everywhere. Subdomain networks accept this too, but there it is usually one operator; cross-TLD makes it a cross-owner risk.
• Trust boundary. Redemption targets need a tight allowlist. Trusting "any site in wp_blogs" would let a single site admin harvest or forge tokens.
• Open redirect and replay. Loosening core's same-host redirect_to clamp invites token leaks, and tokens have to be single-use, short-TTL, and audience-bound against login-CSRF.
• Logout desync. Network-wide login with per-domain logout means that killing a session leaves it live elsewhere.

All of this is solvable with a proper IdP/OIDC-shaped design, but that is well beyond a toggle, so for now it belongs in plugin territory rather than core.

The linked plugin shows the idea, but I would not rely on it as it stands: it has not been updated in three major releases and still targets PHP 7.0, which is unmaintained code in the most security-sensitive area there is.

That gap is a good reason to have the design conversation in the open. So if there is appetite, the right next step is a make/core discussion with a concrete security design. A sensible core-sized slice might be a documented network-login token primitive (on top of the existing set_auth_cookie and send_auth_cookies filters), leaving the cross-domain UX to plugins.