全浏览器默认阻止跨站追踪，多域名场景下SSO如何实现？

Let’s cut to the chase: modern browsers defaulting to cross-site cookie blocking has wrecked the traditional SSO flow that relies on sharing cookies across domains—especially for your setup with dozens/hundreds of regional top-level domains (TLDs) like .ae, .ru, .ca where chaining redirects would kill performance. Here are practical, scalable solutions that actually work:

1. Authorization Code Flow with Server-Side Token Exchange (Top Pick for Your Scenario) #

This is the most widely adopted workaround right now, and it’s perfect for large multi-TLD environments:

• How it works: When a user hits site.ae without being authenticated, they’re redirected to sso.site.com to log in. Once logged in, the SSO service generates a short-lived, one-time authorization code and sends it back to site.ae via a redirect URL. site.ae’s backend then makes a server-to-server call to sso.site.com (this call isn’t subject to browser cross-site restrictions) to exchange the code for long-lived access_token and refresh_token. These tokens are then stored in site.ae’s own cookies (mark them HttpOnly, Secure, and SameSite=Strict for security) or frontend storage (just watch out for XSS risks).
• Why it’s great: No more relying on cross-site cookies, no slow redirect chains, and server-to-server exchanges are way more secure than client-side handoffs. Each domain manages its own tokens, so you don’t have a single point of failure for all regions.
• Pro tips: Make that authorization code expire in 10 seconds max and ensure it’s only usable once. For frontend storage, pair localStorage with strict XSS protections like Content Security Policy (CSP).

2. Web Message-Based Cross-Domain Auth (For Silent, Seamless Logins) #

If you want users to stay on your regional domain without redirecting to the SSO site, use the browser’s postMessage API for cross-domain communication:

• How it works: When site.ae loads, it embeds a hidden iframe pointing to sso.site.com. The iframe checks if the user is logged in, then sends the auth state to site.ae’s frontend via postMessage. If the user isn’t logged in, the iframe can prompt them to log in within the iframe, then send the tokens over once done. The frontend passes these tokens to site.ae’s backend to store in domain-specific cookies.
• Why it’s great: No redirects mean a smoother user experience, and you can implement silent login for returning users.
• Pro tips: Always validate the origin of incoming postMessage data to block malicious sites from faking auth tokens. Encrypt the token data before sending it over to prevent snooping. Note that some browsers restrict hidden iframes for cross-domain communication, so have a fallback redirect flow ready.

3. Centralized Session Store + Per-Domain Token Generation #

For your large-scale setup, a centralized session system paired with per-domain tokens is a robust long-term solution:

• How it works: When a user logs in at sso.site.com, their session data is stored in a high-availability centralized store (like Redis). When they visit site.ae, site.ae’s backend directly queries this centralized store to check if the user has an active session. If they do, site.ae generates its own domain-specific auth tokens and stores them in local cookies.
• Why it’s great: Completely bypasses cross-site cookie restrictions, scales effortlessly to hundreds of domains, and each domain controls its own token lifecycle. Performance is top-tier since there’s no redirect or client-side back-and-forth.
• Pro tips: Ensure the communication between your regional backends and the centralized session store is encrypted (use TLS 1.3+). Make the centralized store highly available with multiple replicas to avoid downtime.

4. OAuth 2.0 PKCE Flow (For Frontend-Only Apps) #

If you have pure frontend apps (no backend) in your stack, PKCE (Proof Key for Code Exchange) is the secure way to go:

• How it works: The frontend generates a random code_verifier and a hashed code_challenge, then sends the challenge to sso.site.com. After login, the SSO returns an authorization code, and the frontend uses the original code_verifier to exchange the code for tokens, which are stored in the frontend (like sessionStorage).
• Why it’s great: No backend required for token exchange, and PKCE prevents attackers from stealing authorization codes to get tokens.
• Pro tips: Use sessionStorage instead of localStorage to limit token exposure if the user has multiple tabs open. Implement silent token refresh using hidden iframes to avoid forcing users to log in again frequently.

A quick note on the old "shared TLD cookie" trick: that only works if all your domains are under the same top-level domain (like .com), which they aren’t in your case, so skip that entirely.

For your international multi-TLD setup, Option 1 (Authorization Code Flow with server-side exchange) is the most practical out of the box, while Option 3 (Centralized Session Store) is ideal if you want to build a custom, highly scalable system long-term.

内容的提问来源于stack exchange，提问作者mailman_73