From another discussion:

In T226797#8458653, @Tgr wrote:

I think the minimum-effort temporary fix would be to send the user to Special:CentralAutoLogin/checkLoggedIn when they visit the login page and the CentralAuthAnon localStorage / cookie key is not set (ext.centralauth.centralautologin.js does that already, but via AJAX so it gets subjected to TCP state partitioning while a top-level redirect would not) and make Special:CentralAutoLogin add an extra query parameter on an unsuccessful return to avoid an infinite redirect cycle. That's just a few lines of code changes and enough to unbreak privacy sandbox type issues which limit cookie access on embedded navigation but not top-level navigation, and the change should be mostly invisible to the user, I think (other than the login page loading a little slower when they are not logged in centrally + if something breaks in CentralAuth they might end up on an error page on loginwiki which is confusing but hopefully very rare).

We'll need a new key alongside CentralAuthAnon since there is no reason not to keep attempting autologin embedded as a script (right now that still works on default, non-incognito Chrome, so it should still work for most users) but we need to track the failure of that separately from the hopefully-more-successful top-level autologin. But other than that, this is the plan.

Change 877987 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/CentralAuth@master] [WIP] Try central autologin via redirects on login page

https://gerrit.wikimedia.org/r/877987

Testing notes:

• Needs a CentralAuth setup with $wgCentralAuthLoginWiki set and a wiki that is not in $wgCentralAuthAutoLoginWikis (not mandatory but makes testing simpler), e.g. dev.wiki and login.wiki on Vagrant with the CentralAuth role and $wgCentralAuthAutoLoginWikis = []; in settings.d.
• Scenarios tested:
  • centrally logged in, locally logged out: when visiting Special:Userlogin, you get logged in via top-level autologin; returnto/returntoquery parameters are honored
    • (note that that you would get logged in without this patch as well, via the old mechanism; you can break it in ext.centralauth.centralautologin.js by commenting out the mw.loader.load line)
    • also works when the account does not exist locally
  • not centrally logged in: login via Special:Userlogin works, including multistep login
  • not centrally logged in: when visiting Special:Userlogin twice, it only attempts top-level autologin once
  • not centrally logged in: when visiting Special:Userlogin, logging in, logging out, and visiting Special:Userlogin again, it attempts top-level autologin again (ie. failure cookie is cleared after successful login)
  • manually crafted returnUrlToken (e.g. http://<login wiki>/wiki/Special:CentralAutoLogin/checkLoggedIn?type=redirect&returnUrlToken=123&wikiid=wiki&proto=http) fails with a reasonably-looking error page
  • logs to CentralAuth channel as expected
• I could not reproduce the actual browser limitations this is supposed to work around, just tested that the top-level autologin works. Typically 3rd-party browser limitations are only triggered by requests across different second-level domains, so I figured it will be easier to test that in production.

We should probably figure out what metrics we can use (or need to add) to see how much effect this has. (We might want to review authentication-related metrics anyway for the introduction of temp users via T300263 & co). There are some authevents log events for central autologin, although not present on the authentication-metrics or authentications dashboards; that could be a start.

In T326281#8522536, @Tgr wrote:

We should probably figure out what metrics we can use (or need to add) to see how much effect this has. (We might want to review authentication-related metrics anyway for the introduction of temp users via T300263 & co). There are some authevents log events for central autologin, although not present on the authentication-metrics or authentications dashboards; that could be a start.

Filed as T327046: Improve (or identify) monitoring for CentralAuth autologins on Wikimedia wikis.

If I understand correctly, this is not yet ready for any Tech News announcements. I will move it to the appropriate workboard column. When it is ready (estimates appreciated), please change the column again, or comment here, or ping me. Please also suggest some draft wording for the Tech News entry. Thank you!

It will be ready when the patch is merged. Draft wording: When you are logged in on one Wikimedia and visit a different one, the system tries to log you in there automatically. The way this is done was changed to make it more reliable. If you feel it's working better or worse than it used to, your feedback is appreciated. [https://phabricator.wikimedia.org/T326281]

Platform Engineering (cc @daniel) could we please have some of your time to review the patch for this task?

Platform Engineering (CC @daniel) tagging you to check if you saw Kosta's last comment and if you have a response.

@MShilova_WMF @kostajh: I'm not very knowledgable about this topic. I will try to find time to learn about it. Unfortunately, we don't have anyone with deep knowledge of SSO on the team.

Considering that this is critical functionality, my priority is to get it right, rather do it fast. I have asked our EMs to get this onto the roadmap.

Adding some keywords to make this task easier to find. I've had the same idea and I'm glad someone is already working on it.

I could not reproduce the actual browser limitations this is supposed to work around, just tested that the top-level autologin works. Typically 3rd-party browser limitations are only triggered by requests across different second-level domains, so I figured it will be easier to test that in production.

To reproduce state partitioning, you do need more than one "registrable domain", although the domains do not actually have to be registered. My CentralAuth test setup has multiple registrable domains in /etc/hosts, with a shared self-signed certificate for HTTPS.

Change 877987 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] Try central autologin via redirects on login page

https://gerrit.wikimedia.org/r/877987

In T326281#8542466, @Tgr wrote:

It will be ready when the patch is merged. Draft wording: When you are logged in on one Wikimedia and visit a different one, the system tries to log you in there automatically. The way this is done was changed to make it more reliable. If you feel it's working better or worse than it used to, your feedback is appreciated. [https://phabricator.wikimedia.org/T326281]

I've added this to https://meta.wikimedia.org/wiki/Tech/News/2023/37 -- if any changes are needed, please edit it there within the next ~24 hours. Thanks again for the draft!

Tested by logging in on en.wikipedia.org, then visiting www.mediawiki.org (without "Keep me logged in" option):

I think we can call that a victory (for now; as noted in T345245, browser vendors are actively thinking about bounce tracking mitigations).

We don't really have useful logs (I did not get T327046 done in time); total autologins went up by ~10-20% but it's hard to know if that's related:

hive (event)> SELECT day, count(*) FROM centralauth WHERE year=2023 AND month=9 AND event.action='sul2-autologin-fallbacklogin' GROUP BY day;
day	_c1
1	12579
2	11507
3	12159
4	12335
5	12144
6	12989
7	14076
8	14041
9	10917

Caused T345700: TypeError: Argument 1 passed to MediaWiki\Extension\CentralAuth\CentralAuthUtilityService::detokenize() must be of the type string, null given, called in /srv/mediawiki/php-1.41.0-wmf.25/extensions/CentralAuth/includes/Special/ but it seems very minor (manual tampering with the URL?).

Change 964312 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/CentralAuth@master] Clean up centralautologin.js after top-level autologin patch

https://gerrit.wikimedia.org/r/964312

Change 964312 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] Clean up centralautologin.js after top-level autologin patch

https://gerrit.wikimedia.org/r/964312