MediaWiki Product Insights/Responsible Reuse/WE5.1: Developer authentication and authorization
We currently have limited ways to identify who is responsible for automated traffic and, unlike on-wiki, limited ways to contact users or regulate their access. We want to evolve our services for developer authentication and authorisation, so that we can better understand who is making requests to our APIs.
Our aim is to increase the percentage of automated traffic that can be attributed to a known account, by requiring strong identification for high volume scraping and API use. This will help us to identify who is reusing content at scale, enabling us to protect our infrastructure and improve governance around fair use, in line with our API Usage Guidelines.
We also want this work to help drive towards a more cohesive developer experience, by starting the work to consolidate methods for developer authentication over the longer term. This should make it easier for developers to obtain the most appropriate level of access and provide a more seamless experience across the different services we offer.
Key problems
[edit]- How can we better protect our infrastructure from high levels of automated traffic?
- How can we encourage developers to use supported channels for content reuse?
- How can we continue to enable the community while putting boundaries in place?
- How can we work towards a more cohesive developer authentication experience?
Target outcomes
[edit]- Know more about who is using our APIs: We are able to improve governance around our APIs by distinguishing between internal, community and commercial usage, and have the ability to contact developers who are generating a high volume of traffic.
- Encourage responsible use of infrastructure: We are able to better protect our infrastructure against high-volume commercial usage, by ensuring that developers are using the most appropriate channels, giving us the ability to prioritise our human users.
- Improve the auth*n experience for developers: Encourage the use of our preferred methods for identifying and authenticating automated traffic, by making this easier for developers and working towards unified developer authentication across services.
Approach
[edit]We will increase the percentage of automated traffic that can be attributed to a known developer or application, by using multiple identification methods to identify who is reusing content at scale and assigning them an appropriate tiered level of access.
This includes:
- Encouraging the use of authentication to strongly identify API users
- Applying request-based rate limiting tiers based on identification rules
- Considering secondary limits (e.g. concurrency) to further protect infrastructure
- Exploring longer term options for consolidating developer authentication
Our approach should take into account:
- Existing authentication methods: Any use of authentication must integrate with existing identity providers, ensuring seamless access for community and enterprise accounts.
- Community concerns around access: We must prioritise support for volunteer-developed community tools and researcher access, whilst encouraging sustainable and efficient usage.
- Identification versus authentication: Identification does not require strong authentication in all cases. We should walk this line with nuance to minimise the impact on the community.
- Analysis of existing traffic patterns: When defining traffic groups and their associated rate limits, this must be informed by measurement of existing traffic to ensure fair and appropriate impact.
Timeline
[edit]Limits were deployed in phases, with the high-level timeline as follows. The process was tracked on Phabricator under T412585.
| Beginning of February 2026 | Dry run of the rate limiting infrastructure, collecting data and verifying proposed limits. |
| End of February 2026 | Announce the deployment of global API rate limits to technical communities. |
| Beginning of March 2026 | Enforce limits for unauthenticated and browser traffic. |
| End of April 2026 | Start to enforce limits for regular bot traffic. |
| End of May 2026 | Fully enforce limits to documented levels. |
| June 2026 | Assess impact of rate limits, determine any need for further adjustments. |