Change Details

CentralAuth relies on the concept of a central login wiki (e.g. login.wikimedia.org for Wikimedia wikis), but (despite what the terminology might suggest) it's not where login actually happens. Users enter their credentials in their home wiki and get logged in there, and the the central login wiki is used, through an elaborate series of redirects, to create a central session (essentially, a cookie stored on the central login wiki) and look up it to authenticate the user on other wikis. This has the benefit that the user never leaves the wiki they are familiar with and the wiki community can customize the login and signup page (e.g. indicate username requirements specific to that wiki), and and administrative tools such as blocks and AbuseFilter filters also behave more naturally. But it causes a lot of problems: * Since the user expects they might need to enter their password on any wiki (even more so with central login not working reliably), an XSS vulnerability on any wiki can easily be escalated into password theft. It's hard to meaningfully monitor hundreds of wikis, and these wikis are often by design less secure than the central login wiki (more people can deploy sitewide JS, there are more gadgets and so potentially more vulnerabilities etc). A separate wiki that's only used for entering login credentials could easily be locked down to the extent where XSS on another wiki in the same farm cannot be used to interfere with login. ({T190019}) * The redirects used for central login are indistinguishable from user tracking, from a browser's perspective; and browsers increasingly break it to prevent tracking. ({T345249}) * Related to the previous point, the authentication flows that browser vendors expect all involve a single SSO domain (without the historical baggage of CentralAuth, it's just a much more natural way of doing things) so that's what they build their heuristics on (e.g. they consider it suspicious if a domain wants to set cookies but the user has never interacted with it) and that assumption is built into web APIs (e.g. the concept of a service domain in {T345589} or the login flow in {T335851}). * Various authentication-related data is stored per domain by the browser (e.g. cookies, passwords, WebAuthn {T248339}) so having many wikis severely degrades the user experience of authentication, and degrades privacy (e.g. there is no practical way to delete your authn cookies on all Wikimedia projects) and security (it's easier to notice you are being phished if you always log in on the same domain, e.g. because you can expect the password to be prefilled). We need to disable local login and use a central, single location where the user interacts with credentials. This includes at least login, signup, password change, password reset; arguably also bot passwords and OAuth. ---- There are a couple ways to do this: * Minimal-effort version: Have Special:UserLogin etc. redirect to loginwiki, do the user interaction there (if the user is already logged in, probably just show a button to confirm identity, to fulfill interaction requirements for bounce tracking prevention heuristics), redirect back on success or failure and prove to the other wiki what happened. Everything else is kept as-is. (Note: the MediaWiki / CentralAuth code change needed for this is pretty small, but many bots and apps would have to be updated, so on the whole not a small project nevertheless.) Or maybe instead of redirection, embed loginwiki as an iframe. * Use FedCM ({T335851}) if it becomes available, which is vaguely similar (and requires a non-FedCM fallback in any case, for older browsers and non-browsers) but requires a couple extra APIs and a "popup" layout for the login form. * As above, but also rethink session handling (as the half dozen auth cookies used by MediaWiki don't make that much sense when login is happening elsewhere) and use something like JWT cookies (e.g. OAuth 2 access tokens) instead. * The same but (taking advantage of using an industry-standard format for sessions) replace loginwiki entirely with a small dedicated app to reduce attack surface (cf {T120484}). Note that this would affect a number of important steward workflows so it needs careful investigation. These options could also be done as successive stages (at the cost of some overhead).

CentralAuth relies on the concept of a central login wiki (e.g. login.wikimedia.org for Wikimedia wikis), but (despite what the terminology might suggest) it's not where login actually happens. Users enter their credentials in their home wiki and get logged in there, and the the central login wiki is used, through an elaborate series of redirects, to create a central session (essentially, a cookie stored on the central login wiki) and look up it to authenticate the user on other wikis. This has the benefit that the user never leaves the wiki they are familiar with and the wiki community can customize the login and signup page (e.g. indicate username requirements specific to that wiki), and and administrative tools such as blocks and AbuseFilter filters also behave more naturally. But it causes a lot of problems: * Since the user expects they might need to enter their password on any wiki (even more so with central login not working reliably), an XSS vulnerability on any wiki can easily be escalated into password theft. It's hard to meaningfully monitor hundreds of wikis, and these wikis are often by design less secure than the central login wiki (more people can deploy sitewide JS, there are more gadgets and so potentially more vulnerabilities etc). A separate wiki that's only used for entering login credentials could easily be locked down to the extent where XSS on another wiki in the same farm cannot be used to interfere with login. ({T190019}) * The redirects used for central login are indistinguishable from user tracking, from a browser's perspective; and browsers increasingly break it to prevent tracking. ({T345249}) * Related to the previous point, the authentication flows that browser vendors expect all involve a single SSO domain (without the historical baggage of CentralAuth, it's just a much more natural way of doing things) so that's what they build their heuristics on (e.g. they consider it suspicious if a domain wants to set cookies but the user has never interacted with it) and that assumption is built into web APIs (e.g. the concept of a service domain in {T345589} or the login flow in {T335851}). * Various authentication-related data is stored per domain by the browser (e.g. cookies, passwords, WebAuthn {T248339}) so having many wikis severely degrades the user experience of authentication, and degrades privacy (e.g. there is no practical way to delete your authn cookies on all Wikimedia projects) and security (it's easier to notice you are being phished if you always log in on the same domain, e.g. because you can expect the password to be prefilled). We need to disable local login and use a central, single location where the user interacts with credentials. This includes at least login, signup, password change, password reset; arguably also bot passwords and OAuth. ---- There are a couple ways to do this: * Minimal-effort version: Have Special:UserLogin etc. redirect to loginwiki, do the user interaction there (if the user is already logged in, probably just show a button to confirm identity, to fulfill interaction requirements for bounce tracking prevention heuristics), redirect back on success or failure and prove to the other wiki what happened. Everything else is kept as-is. (Note: the MediaWiki / CentralAuth code change needed for this is pretty small, but many bots and apps would have to be updated, so on the whole not a small project nevertheless.) Or maybe instead of redirection, embed the relevant loginwiki form as an iframe. * Use FedCM ({T335851}) if it becomes available, which is vaguely similar (and requires a non-FedCM fallback in any case, for older browsers and non-browsers) but requires a couple extra APIs and a "popup" layout for the login form. * As above, but also rethink session handling (as the half dozen auth cookies used by MediaWiki don't make that much sense when login is happening elsewhere) and use something like JWT cookies (e.g. OAuth 2 access tokens) instead. * The same but (taking advantage of using an industry-standard format for sessions) replace loginwiki entirely with a small dedicated app to reduce attack surface (cf {T120484}). Note that this would affect a number of important steward workflows so it needs careful investigation. These options could also be done as successive stages (at the cost of some overhead).

CentralAuth relies on the concept of a central login wiki (e.g. login.wikimedia.org for Wikimedia wikis), but (despite what the terminology might suggest) it's not where login actually happens. Users enter their credentials in their home wiki and get logged in there, and the the central login wiki is used, through an elaborate series of redirects, to create a central session (essentially, a cookie stored on the central login wiki) and look up it to authenticate the user on other wikis. This has the benefit that the user never leaves the wiki they are familiar with and the wiki community can customize the login and signup page (e.g. indicate username requirements specific to that wiki), and and administrative tools such as blocks and AbuseFilter filters also behave more naturally. But it causes a lot of problems: * Since the user expects they might need to enter their password on any wiki (even more so with central login not working reliably), an XSS vulnerability on any wiki can easily be escalated into password theft. It's hard to meaningfully monitor hundreds of wikis, and these wikis are often by design less secure than the central login wiki (more people can deploy sitewide JS, there are more gadgets and so potentially more vulnerabilities etc). A separate wiki that's only used for entering login credentials could easily be locked down to the extent where XSS on another wiki in the same farm cannot be used to interfere with login. ({T190019}) * The redirects used for central login are indistinguishable from user tracking, from a browser's perspective; and browsers increasingly break it to prevent tracking. ({T345249}) * Related to the previous point, the authentication flows that browser vendors expect all involve a single SSO domain (without the historical baggage of CentralAuth, it's just a much more natural way of doing things) so that's what they build their heuristics on (e.g. they consider it suspicious if a domain wants to set cookies but the user has never interacted with it) and that assumption is built into web APIs (e.g. the concept of a service domain in {T345589} or the login flow in {T335851}). * Various authentication-related data is stored per domain by the browser (e.g. cookies, passwords, WebAuthn {T248339}) so having many wikis severely degrades the user experience of authentication, and degrades privacy (e.g. there is no practical way to delete your authn cookies on all Wikimedia projects) and security (it's easier to notice you are being phished if you always log in on the same domain, e.g. because you can expect the password to be prefilled). We need to disable local login and use a central, single location where the user interacts with credentials. This includes at least login, signup, password change, password reset; arguably also bot passwords and OAuth. ---- There are a couple ways to do this: * Minimal-effort version: Have Special:UserLogin etc. redirect to loginwiki, do the user interaction there (if the user is already logged in, probably just show a button to confirm identity, to fulfill interaction requirements for bounce tracking prevention heuristics), redirect back on success or failure and prove to the other wiki what happened. Everything else is kept as-is. (Note: the MediaWiki / CentralAuth code change needed for this is pretty small, but many bots and apps would have to be updated, so on the whole not a small project nevertheless.) Or maybe instead of redirection, embed the relevant loginwiki form as an iframe. * Use FedCM ({T335851}) if it becomes available, which is vaguely similar (and requires a non-FedCM fallback in any case, for older browsers and non-browsers) but requires a couple extra APIs and a "popup" layout for the login form. * As above, but also rethink session handling (as the half dozen auth cookies used by MediaWiki don't make that much sense when login is happening elsewhere) and use something like JWT cookies (e.g. OAuth 2 access tokens) instead. * The same but (taking advantage of using an industry-standard format for sessions) replace loginwiki entirely with a small dedicated app to reduce attack surface (cf {T120484}). Note that this would affect a number of important steward workflows so it needs careful investigation. These options could also be done as successive stages (at the cost of some overhead).