Exclude OAuth registration and MCP discovery from per-IP limit

Ashwin Srequested to merge
29985-exclude-oauth-dynamic-registration-from-unauthenticated-throttle into master

What does this MR do and why?

On GitLab.com, the unauthenticated per-IP rate limit (unauthenticated_traffic_per_ip, 60 requests an hour per IP, plus its log-mode twin unauthenticated_traffic_per_ip_log) already excludes sign-in steps and OAuth token grants. That was done in !259466 (merged). OAuth dynamic client registration was not in that scope, and the brown-out analysis flagged it afterwards. This MR excludes it, and MCP discovery requests, from the per-IP rule.

Dynamic client registration (RFC 7591) is POST /oauth/register(.:format), handled by Oauth::DynamicRegistrationsController#create. MCP clients call it once, before the user signs in. It carries no credential by design: it creates a public OAuth application (dynamic, PKCE required). There is nothing for the rate limiter to resolve, so an exclusion is the only fix.

Data for the 24 hours ending 2026-10-06:

  • 42.8k requests a day. 19.4k (45%) would be blocked once the per-IP rule is enforced.
  • 23.7k were successful. 3.3k (14%) of those would be blocked. They came from IPs that were under the dedicated 10/hour registration limit but had already used their shared 60 on other anonymous requests.
  • 19.1k a day already get a 429 from the dedicated limit.

The dedicated limit stays: oauth_dynamic_registration, 10 an hour per IP, which returns a JSON 429 with Retry-After. The path keeps a tighter per-IP cap after the exclusion.

MCP clients also fetch OAuth metadata documents before signing in. Volume is about 9 requests a day across these, so this rounds out the MCP sign-in flow rather than fixing volume.

Known tradeoffs

  • Failing registrations leave the per-IP rule too. They stay under the dedicated 10/hour limit, which already rejects 19.1k a day.
  • /o/:organization_path/ copies of the discovery documents are not matched, same as the existing discovery matcher.
  • Authenticated users on these paths still count against their plan's per-user limits.

References

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/work_items/29985

Merge request reports