Hi,

I am writing on behalf of the company I work for (Seznam.cz). We are providing a large number of various online services in Czech Republic, operating a nontrivial number of domains (think 10-15) and serving millions of users.

For years, we were able to maintain a working solution for signing users into our services, but various anti-tracking measures adopted by browsers in recent years are making this very hard for us - basically because we rely on techniques that are hard to separate/distinguish from malice/tracking.

What do we want

• a single sign-on point for our users
• a user visiting domain A.cz can sign-in, then visits other service at B.cz and will be auto-magically signed-in there as well

What do we do currently

1. provide sign-in services on a dedicated domain S.cz - storing the state in a cookie C1 for the S.cz domain
2. redirect users to a particular service-domain A.cz/B.cz/... via temporary url-based secret (think oauth authorization_code) - storing the state in a cookie C2 for the A.cz/B.cz/... domain
3. try to provide background synchronization of the said sign-in state when the user visits C.cz:
   • a) via JS-based "POST S.cz" (suboptimal: needs 3rd party cookie access)
   • b) via top-level navigation redirect "to S.cz and back" (suboptimal: can be easily confused with link decoration, does not refresh cookie C1 at S)

This approach allows us to set C2 cookies with SameSite=Lax (good for CSRF prevention) while having C1 cookies with SameSite=None (necessary for the request mentioned at 3a)

What are we running into

• browsers limiting our ability to synchronize state S.cz -> C.cz via approach 3a
• browsers expiring our cookie C1 for S.cz (the main "source of truth"), because S.cz does not offer real content (is used only for sign-in)
• weird UX when redirecting via approach 3b, unclear whether this redirection will be considered an abuse in near future

What did we try

• moving the sign-in service from a dedicated S.cz domain to one of our "real" service domains (A.cz)

  • -> we lost the ability to set C1 as SameSite=Lax
  • -> we still need to sync the state from A.cz to B/C/...

• implementing FedCM

  • -> poor UX, because users need to interact explicitly with the browser UI (strictly worse when compared to what we do today)
  • -> poor browser support
  • -> does not work then the sign-in state changes at S.cz (cookie C1), but there is an existing valid cookie C2 at A.cz/B.cz

To sum things up: what are our options if we want to provide our services on multiple domains and we want to automatically synchronize/maintain sign-in state across these domains, without being punished for tracking-like behavior?