WordPress SSO across different domains has a reputation for being technically complex. That reputation is not entirely undeserved. If you try to implement it using OAuth 2.0 protocols, SAML identity providers, or custom JWT authentication middleware, it absolutely is complex. You are looking at server configuration, certificate management, protocol debugging, and the kind of work that usually requires a developer who has done it before.
But there is a different category of WordPress SSO setup that does not require any of that. When you want to connect two or more independent WordPress sites on different domains so that users can log in once and move between them freely, the solution is a purpose-built plugin that handles the cross-domain authentication layer for you. The setup process reduces to: install the plugin, enter the other site’s URL, copy an API key, paste it on the other site, and turn SSO on. That is it.
This guide walks through that process step by step, explains what is actually happening at each stage so you understand what you are configuring and why, and covers the most common questions that come up when setting up cross-domain SSO for the first time. By the end, you will have a working SSO connection between two WordPress sites on different domains, with a clear understanding of how to extend it to additional sites in your network.
Why cross-domain SSO is a different problem from same-domain SSO
On the same domain or subdomain, SSO is relatively straightforward because browser cookies can be set with a shared domain scope. A cookie set on example.com is readable by shop.example.com and members.example.com. The session can be shared at the cookie level without any special cross-site communication.
Across completely different domains, this does not work. A cookie set on siteA.com is not readable by siteB.com. The browser’s same-origin policy prevents it by design, as a security measure. This is why cross-domain SSO requires a different technical approach: rather than sharing a session cookie, the two sites need to communicate directly with each other to verify authentication state.
When a user who is logged into Site A visits Site B, Site B generates a request to Site A’s API asking whether this user has an active session. Site A responds with a signed, time-limited token confirming the session. Site B validates the token’s signature against the shared API key, creates a local session for the user, and the user arrives at Site B already logged in. The entire exchange happens in milliseconds and is invisible to the user. No shared cookies. No external identity server. Just two sites talking directly to each other through a secured API channel established when you configured the connection.
This architecture is more robust than shared-cookie approaches because it works regardless of browser privacy settings, cookie blocking policies, or domain structure. It works between any two WordPress sites that can reach each other over HTTPS, regardless of where they are hosted or what domains they use.
Prerequisites before you start
Before walking through the setup steps, confirm that your environment meets these requirements. None of them are unusual for a production WordPress site, but it is worth checking before you start.
The complete step-by-step setup
The following steps take you from two completely unconnected WordPress sites to a working cross-domain SSO setup. In most cases, the entire process takes under 20 minutes.
Site A refers to your primary site, the one where most users originally register and log in. Site B refers to the secondary site that you want users to access without logging in again. If you have more than two sites, repeat the connection steps for each additional site.
Testing the SSO connection
Before announcing the setup to your users, run through this verification sequence to confirm everything is working correctly.
Log in to Site A with a test account that you confirmed exists on both sites (use an account that was included in the bulk sync). Open a new browser tab and navigate to Site B. You should arrive already logged in. If you are prompted to log in, the SSO trigger mode may need adjustment or there may be a caching layer interfering.
Register a brand new test account on Site A. Wait 10 seconds, then check Site B’s Users screen. The new account should already exist on Site B. Check the Logs tab to confirm the sync event was recorded with a success status.
Log in to Site A with the newly registered test account. Navigate to Site B. You should be logged in automatically even though this account was created after the bulk sync ran. This confirms that real-time sync and SSO are working together correctly for new registrations.
While logged in to both sites, log out of Site A. Then attempt to access a logged-in page on Site B. If you configured global logout, you should be logged out of Site B as well. If you configured local logout, you will still be logged in on Site B, which is the expected behavior for that setting.
Troubleshooting the most common setup issues
Most setup issues fall into a small number of categories. Here are the most common ones and how to resolve them.
The most common cause is a firewall rule that blocks outbound HTTP requests from your hosting environment to external domains. Contact your host and ask whether outbound API calls to external HTTPS URLs are permitted. The second most common cause is a security plugin that has restricted the WordPress REST API. Temporarily disable security plugins on Site B and retry the connection check to confirm.
The connection being active (green in the dashboard) confirms the two sites can communicate. If SSO is not working after that, check whether the user you are testing with exists on both sites. A user who only exists on Site A will not be logged in automatically on Site B because there is no account to authenticate against. Run the bulk sync if you have not already, then test with an account that you confirmed exists on both sites.
Inconsistent SSO behavior is almost always caused by a caching layer. If Site B has a full-page cache active (via a caching plugin, CDN, or hosting-level cache), the cached version of the page may be served before the SSO check has a chance to run. Configure your caching setup to exclude logged-in users from the cache, or exclude the pages where SSO needs to work from the cache entirely.
Check the error message recorded in the Logs tab for the failed event. An SSL certificate error means Site B’s certificate is expired or invalid. A 401 error means the API key is not being accepted, which can happen if the key was not entered correctly on Site B. A timeout error suggests a temporary connectivity issue that the retry queue will resolve automatically. A 404 error typically means the plugin is not active on Site B or the WordPress REST API endpoint has been blocked.
Adding a third, fourth, or fifth site to the network
Once your two-site SSO setup is working, adding more sites to the network follows exactly the same process. Install the plugin on the new site, create a new connection in the Connections tab on your primary site, generate a new API key, paste it into the new site, configure the sync settings for that connection, enable SSO, and run the bulk sync. Each additional site is a new connection with its own API key, and the configuration for existing connections does not change.
The Nexu User Sync plugin for WordPress SSO setup across multiple domains supports as many connections as your network requires. Each connection is independent, which means the sync direction, role mapping, field selection, and SSO behavior can be configured differently for each site pair. A connection to your membership portal can be configured differently from a connection to your support community, even though both are connected to the same primary site.
The dashboard gives you a single view of all connections, their health status, and their sync statistics. As your network grows, this view becomes the operational tool that tells you at a glance whether all your connected domains are communicating correctly, without needing to check each site individually.
Cross-domain SSO that takes 20 minutes to set up and then runs itself
Nexu User Sync gives you cross-domain Single Sign-On between any number of independent WordPress sites, with real-time user sync, WooCommerce support, a resilient queue, and full audit logs. The setup is one copy-paste. Everything else runs automatically.
Hey! The direct site to site API connection worked like a charm once I pasted the key
I've set up SSO for multiple WordPress sites in the past, and honestly, this guide made the whole process stupid simple. No wrestling with SAML or dealing with OAuth headaches just install, grab an API key, paste it in, and done. users switch between domains without even blinking at a login screen.
Snagged this during the summer sale, and wow it actually made dealing with subdomain logins a breeze. now my main site's cookies work smooth on shop. and members. without users having to log in twice. setup was crazy easy too; just 10 minutes with the copy paste API key, and the guide's screenshots were super clear. Tried using it between two totally different domains later (like example.com and another.com) and ran into some issues, but for subdomains? absolute lifesaver. Four stars for making my life way easier on that front!