For Wikimedia's central login system (SUL), we want to have a a single domain for storing a central session cookie that other domains (wikis) can rely on for authentication; and we want to do interactive login on that domain (T348388: SUL3: Use a dedicated domain for login and account creation - because browsers increasingly require user interaction with the cookie-storing domain before giving access to cookies); but we want the interaction on that domain to be similar to the interaction on the wiki where the user is logging in (in terms of i18n customizations, AbuseFilter/SpamBlacklist username rules etc).
One way to do this would be for the central login wiki's login page to fetch the relevant information from the origin wiki in a bunch of API calls and customize itself accordingly. This seems like a lot of effort with a long tail of small inconsistencies that will take forever to squash. An alternative approach would be to use a new domain, say https://sso.wikimedia.org/<wiki hostname>/, which would to resolve to the wiki specified in <wiki hostname> (ie. this page would be served by the same wiki from which the user started the login process, but under a different domain). We would limit what URLs can be accessed on this new domain, and add a bunch of config/hook overrides, like limiting what pages can be viewed and limiting user rights to only those needed for login, and maybe splitting some caches.
This would hugely simplify how displaying the central login page would work, although it would complicate the configuration system. I think (although I am not very sure) it would be a simpler approach on the net. It would also be a mixed change in terms of security - the login domain would be very much locked down compared to login.wikimedia.org (a real wiki), which is good, but it could be served by any wiki, ie. any backend code deployed in the Wikimedia cluster could potentially run on it, which is bad.
Also, for the reasons explained in T348388: SUL3: Use a dedicated domain for login and account creation, the URL used for interacting with cookies on the login domain will have to be user-visible (unless we use an iframe, which has security and browser compatibility disadvantages). Given "wikimedia" is less widely recognized than "wikipedia", this might pose its own UX challenges.
See also:
- Decision brief
- T120484: Store CentralAuth password hashes outside the main database cluster (replace loginwiki entirely with a small dedicated app)
- T215071: Merge Wikipedia subdomains into one, to discourage censorship