IdP with background sign-in sync: what are the proper white-hat options today?

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?

Can you expand more on your experience evaluating FedCM?

Can you expand more on your experience evaluating FedCM?

Happily.

-> poor UX, because users need to interact explicitly with the browser UI (strictly worse when compared to what we do today)

FedCM requires explicit interaction with the Browser's UI. Compare that to our current approach, where the user is "automatically signed in" when visiting any of our domains/services (provided they sign-in on our central sign-in domain S.cz beforehand).

Let me repeat our primary user story: 1) visit A.cz 2) sign-in 3) go to B.cz and be signed in as well without any additional interaction

-> poor browser support

Pretty self-explanatory. Will be probably improved in the future, but we need our services to operate today. Our current approaches (named "3a" and "3b" in the original issue text) work in all current browsers.

-> 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

Let me describe this scenario in more detail.

1) user signs in at S.cz 2) user visits A.cz 1) FedCM is invoked and used to provide relevant login secret to A.cz 2) note that further A.cz visits do not invoke FedCM, because the user is now signed-in to A.cz 3) user deletes their S.cz cookie (this includes automatic cookie deletion due to longer-term inactivity at S.cz) 4) user visits B.cz 1) FedCM is invoked; the account list is empty (missing S.cz cookie) 2) user visits S.cz again, signs in, the new secret is transferred to B.cz 5) user visits A.cz again 1) inconsistency: A.cz still uses the valid-but-obsoleted cookie, FedCM is not invoked, there is no way to forward the new secret from S.cz to A.cz

@samuelgoto is your source on FedCM. An alternative if you had less supported websites would be Related Website Sets, but it's limited to up to 5 associated domains and you have 10-15.

About whether 3B will be considered abusive in the future: 3B is very much the kind of silent-tracking usage pattern Bounce Tracking Mitigations is designed to detect and mitigate, but we recognized that it is common for SSO systems like the one you describe and so we have a special catch to keep such sites from major breakage. Your flow will be mostly protected by the interactions generated when the user is signing in on S.cz—Chrome will detect this as potentially not tracking, but decline to act if there was interaction on S.cz within the last 45 calendar days.

If you already expect users to sign in on S.cz more frequently than every 45 days (say, monthly), you won't see an impact. Beyond that timeline, you might see C1 getting cleared, and in your system that might mean the user needs to sign in again (and resetting the 45 day timer).

Hi @BrianLefler, thanks for your answer!

About whether 3B will be considered abusive in the future: 3B is very much the kind of silent-tracking usage pattern Bounce Tracking Mitigations is designed to detect and mitigate, but we recognized that it is common for SSO systems like the one you describe and so we have a special catch to keep such sites from major breakage.

I am completely in favor of not doing this kind of silent redirection, provided that an alternative solution is feasible. In my opinion, these redirects are detrimental to UX and introduce their own set of complex issues (apart from the fact that they are hard to distinguish from malice/tracking). So if there was another way of forwarding the state from S.cz to Cn.cz, I would eagerly implement that, leaving redirects back in the "tracking" realm.

If you already expect users to sign in on S.cz more frequently than every 45 days (say, monthly), you won't see an impact.

Ideally, we would like our users to "sign once, use forever". This of course does not include more advanced cases like multi-accounts or shared computers. But the majority of regular users shall visit S.cz only once. We are already hitting the cookie deletion period in mobile Safari (30 days methinks) and this fact is kinda worrying for us - because the auto-deleted C1 effectively means "sign off" (there is no longer a working authoritative cookie).

Happily.

Thanks for expanding, I think I understand where you are at.

I think the following are the key observations:

we rely on techniques that are hard to separate/distinguish from malice/tracking. user is "automatically signed in" when visiting any of our domains/services

You can't have a system with those two properties at the same time, because "automatically signed in" is, as you suggested, not "dististinguishable from malice/tracking".

So, you have to either relax on "automatically signed in" or "distinguishable from malice/tracking".

In Chrome, If you can relax on "automatically signed in", there are currently two options (with their own trade-offs): FedCM and SAA.

If you can relax on "distinguishable from malice/tracking", in Chrome, you have a few more: Related Website Sets (which is limited to up to 5 associated domains and you have 10-15 -- precisely because, if it was unlimited, it would make it hard to distinguish from malice/tracking) and heuristics (which, as you suggested in "leaving redirects back in the "tracking" realm", is gameable: we just don't know how easily yet).

what are the proper white-hat options today? FedCM requires explicit interaction with the Browser's UI.

I think FedCM is likely the most "white-hat" option you'd have today, but it is going to require you to relax your "automatically signed in" requirement (because, as I articulated, that's what makes it indistinguishable from malice/tracking).

Emphasis on the automatically part.

The UI was designed specifically to strike the right balance between user comprehension (to make it distinguishable from malice/tracking) and performance (low-friction enough to hold reasonable conversion rates).

I'm not particularly married to the specific UI we are showing and we'd be happy to explore other UI variants, but as a rule of thumb, we require an explicit user signal. If you have suggestions on how to make the UI better (within the constraint of an explicit user signal), we'd love to hear.

We are already hitting the cookie deletion period in mobile Safari (30 days methinks) and this fact is kinda worrying for us - because the auto-deleted C1 effectively means "sign off" (there is no longer a working authoritative cookie).

Much in Safari, Chrome and Firefox is still evolving, but that's why I'm suggesting FedCM as the most "white-hat" option (I don't know if I'm over-indexing on the term white-hat, LMK if that's the case), because anything outside of an explicit user prompt is going to fall into a game-theoretical cycle: abuse is going to show up, browser interventions are going to try to make them economically impractical, until we (a) find a stable equilibrium or (b) we don't and loop back into a cycle.

You have a few options (e.g. i think it is rational and valid for you to bet on heuristics and project that we'll find a stable equilibrium), and they may vary across browsers, but in case you can relax on "automatically signed-in" and are interested in extending / fixing FedCM I'd love to hear more from you.

-> 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

Just so that I understand what's holding you back here, if this problem was addressed, would it unblock you (given the other two constraints remained, i.e. explicit user gesture and poor cross-browser support)?

Hi @samuelgoto ,

thanks for your response. I would say that I am now almost sufficiently knowledgeable regarding our options to report back to our management.

FedCM and SAA.

What exactly is SAA, please? I do not recall seeing this acronym wrt sign-in.

I think FedCM is likely the most "white-hat" option you'd have today, but it is going to require you to relax your "automatically signed in" requirement

Right. I am completely okay with the "white-hat" terminology here. Actually, that was almost literally my management's request before exploring our options via this issue; to quote: "we had a sufficient automatic sign-in system that worked for years and our intents are completely white-hat; why are they breaking our things now?"

To elaborate a little bit more on the "auto-deletion of the S.cz cookie" case: if we were to use FedCM, would the browser take special care of our IdP's S.cz domain, not auto-deleting the C1 for inactivity? Because even with a FedCM-based identity delegation, we would still want to be able to remain signed-in (centrally, via S.cz) for a long time (i.e. way longer than 30 or 45 days).

Just so that I understand what's holding you back here, if this problem was addressed, would it unblock you (given the other two constraints remained, i.e. explicit user gesture and poor cross-browser support)?

It is now very early to tell; our experimental FedCM implementation is going to be released for a small subset of use-cases during this week. I am pretty certain that we are going to be providing multiple mechanisms in parallel (FedCM being one of them), watching their usage and potential issues. And we will keep you posted on FedCM-specific stuff in the FedCM repo -- I raised this issue mainly to gather a higher-level overview about all options currently available.

What exactly is SAA, please? I do not recall seeing this acronym wrt sign-in.

Ah, apologies for the acronymization here, my bad.

Storage Access API: it is (a) easier to use and (b) works across all major browsers (Safari, Chrome and Firefox) -- so it checks that box in your list --, but will likely have a even more abrupt / low-conversion user prompt. So, ergonomics and reach in exchange for user comprehension (which materializes in lower conversion rates).

To elaborate a little bit more on the "auto-deletion of the S.cz cookie" case: if we were to use FedCM, would the browser take special care of our IdP's S.cz domain, not auto-deleting the C1 for inactivity? Because even with a FedCM-based identity delegation, we would still want to be able to remain signed-in (centrally, via S.cz) for a long time (i.e. way longer than 30 or 45 days).

Let me read more about and digest what you want to do here and I'll report back.

It is now very early to tell; our experimental FedCM implementation is going to be released for a small subset of use-cases during this week. I am pretty certain that we are going to be providing multiple mechanisms in parallel (FedCM being one of them), watching their usage and potential issues. And we will keep you posted on FedCM-specific stuff in the FedCM repo -- I raised this issue mainly to gather a higher-level overview about all options currently available.

That's great to hear.

And my offer stands: if there are ways that we could make the FedCM prompt perform better for your users, we'd love to hear and make it better. Don't take it as an immutable API, but rather a starting point that we can iterate from.

privacycg / nav-tracking-mitigations