auth.wikimedia.org
auth.wikimedia.org is the domain used for sharing authentication-related cookies between wikis using unified login. It is served by MediaWiki, but it does not correspond to a specific MediaWiki database; instead, it can use any database (and in effect, assume the behavior of any wiki), similar to upload.wikimedia.org or (in the past) secure.wikimedia.org. It was created as part of the SUL3 project.
auth.wikimedia.org is handled mostly via custom configuration and CentralAuth hooks (for more details see T363695 and T378722). The URL format is similar to other wikis but with a DB name prefix (e.g. https://auth.wikimedia.org/enwiki/wiki/Special:UserLogin). All functionality unrelated to authentication is disabled; only login, signup, credentials change, and a few generic API endpoints work.
As of 2026, you can prevent authentication workflows from using the auth domain by adding usesul3=0 (e.g. https://en.wikipedia.org/wiki/Special:UserLogin?usesul3=0). This is not intended to remain forever, and should not be relied on.
Developing PHP code running on auth.wikimedia.org
Other than a lot of endpoints being unavailable, MediaWiki code behaves mostly the same way on the auth domain, but there are a few gotchas to keep in mind:
$wgServerand$wgCanonicalServerwill use theauth.wikimedia.orgdomain name but other ways of obtaining a server name (e.g. via WikiMap) will usually use the original wiki's domain name.- ResourceLoader assets will be loaded from the original domain (
$wgLoadScriptwill use the original domain name) so there is no way to pass auth-domain-specific variables to JS code (without a lot of hacks, anyway). - Code using the GetLocalURL hook (including Title objects and wikitext parsing) will autodetect whether a given page should be accessed on the auth domain or the original domain, and use the appropriate URL.
- The various MediaWiki internal caches are not split. If you generate some data differently on the auth domain, you should make sure not to cache it there.
If you need to debug issues in production, you can set the MW_USE_SHARED_DOMAIN=1 env variable to apply auth domain customizations to an arbitrary CLI PHP process (e.g. shell.php).
Developing JS code running on auth.wikimedia.org
- As with PHP, the value of the
mw.configvariablewgServerwill be//auth.wikimedia.org). You can usewgServerName(e.g.en.wikipedia.org) instead to construct links back to the wiki the user is coming from.- Unlike in PHP, there is no way to autodetect whether a link to a given title should go to the auth domain or the original one. If you want to link to a potentially authentication-related special page, you need to check CentralAuth's
SharedDomainHookHandler::DEFAULT_RESTRICTIONS/$wgCentralAuthSul3SharedDomainRestrictionsconfiguration and hardcode the logic.
- Unlike in PHP, there is no way to autodetect whether a link to a given title should go to the auth domain or the original one. If you want to link to a potentially authentication-related special page, you need to check CentralAuth's
- Cookies, sessions etc. are not shared between the original wiki and auth.wikimedia.org. The AuthPreserveQueryParamsHook can be used to preserve URL query parameters when users transition from the local login etc. page to the auth domain.
