MediaWiki Platform Team/SUL3

Group:	MediaWiki Platform Team
Backlog:	#sul3
Lead:	Tgr_(WMF)
Management:	JTweed-WMF

Single User Login (SUL) provides central authentication that ensures users have a single identity across all Wikimedia projects, including the ability to log in on one wiki and be automatically logged in across all wikis. SUL3 changes this so that all account creation and login happens on a dedicated domain, to ensure compatibility with browser anti-tracking features. It is designed to fully replicate the existing experience, including all per-wiki customisation.

Approach

Why we need to change

When a user visits a wiki, the browser sends a request to login.wikimedia.org to retrieve the central session. As there is no user interaction on login.wikimedia.org, this is increasingly blocked by browsers trying to prevent cross-domain tracking cookies.

To prevent browsers from blocking these cookies, we need to ensure user interaction on the central domain. This requires us to move the login and signup forms from individual wikis to the central domain. As it currently hosts Login Wiki, which will continue to exist to support existing workflows, it is difficult to reuse the login.mediawiki.org domain for SUL3.

What will change

When a user clicks on Create account or Log in, they will be redirected to a new central authentication domain. The page displayed will have a URL on the central domain, but will render as if the user was still on the original wiki. Once logged in, the user will be redirected back to the original wiki and autologin to other wikis will work as it does today.

URLs on the central authentication domain will be of the form:

https://auth.wikimedia.org/{wikiid}/{page}

Eg:

https://auth.wikimedia.org/enwiki/wiki/Special:Userlogin

Considerations

In determining the best approach to SUL3, we wanted to:

Minimise UX changes: Minimise the non-essential changes that users experience, by preserving current flexibility and customisation of the wikis.
Maintain account security: Reduce the risk of unknown vulnerabilities by limiting changes to security-critical code and moving all interactions to a single domain.
Improve platform sustainability: Limit the number of authentication mechanisms to minimise technical debt and improve the long-term sustainability of the platform.

Impact


Group	Impact
Temporary accounts	SUL3 is fully compatible with temporary accounts and we will actively work to resolve any issues identified during testing and rollout.
Registered users	Registered users should see no material difference in experience, with the only visible change being the new URLs. They may need to update their password manager, if they use one.
Stewards	CheckUser workflows, including cross-wiki on loginwiki, will continue to work as they do today.
API users	SUL3 will not be enabled by default for the clientlogin API call, we may offer a flag for testing and migrating to the new flow.

Deployment

We intend to deploy SUL gradually, so that any problems can be identified before they affect a large number of users. We will also closely monitor authentication metrics, including new account creation and login rates, to ensure that this change has not had a negative impact.

We are currently creating a full plan for the deployment of SUL3, but are aiming for it to be on all test wikis by the end of Q2 [Dec 2024]. We intend to roll out to all wikis in Q3 [Jan–Mar 2025].