Page MenuHomePhabricator

Disallow public access to OAuth client ID management API
Closed, ResolvedPublic


To support the API Portal, the OAuth extension will include a set of REST endpoint that allow the Portal to create, list, and reset secrets for OAuth clients. The purpose of this task is to address the issue of access to these endpoint from the public internet.

To do:

  • Discuss whether it is an issue that these endpoints are exposed to the public internet
  • Investigate ways to address this issue
  • Prioritize the implementation effort in relation to the API Portal implementation plan
  • Implement the solution


The OAuth extension, as configured on, requires that a user be logged in with a valid Wikimedia account to use the endpoints.

Event Timeline

apaskulin updated the task description. (Show Details)
apaskulin added a subscriber: apaskulin.

I do not believe this an actual security concern from a technical/code perspective. However, it may be a concern from a policy/legal perspective.

The endpoints do appropriate session checks, so exposing them publicly doesn't allow anyone to do things they would not otherwise be allowed to do. However, it does potentially allow someone to create a client without viewing/acknowledging the Application Policy (which says, among other things, that we can turn off your client if we feel like it). I don't know how strongly we feel about that.

So, I heard from @Pchelolo that the API Portal key management interface calls the API directly from the browser? @BPirkle @CCicalese_WMF can you confirm?

If that's the case, then we can close this; we can't make the API private if it's called from the public.

I think it's probably necessary to be more careful about the API if it's public, though.

So, I heard from @Pchelolo that the API Portal key management interface calls the API directly from the browser? @BPirkle @CCicalese_WMF can you confirm?

Confirmed, with the caveat that I'm not sure about current status, so I'm not sure whether to say "calls" or "will call".

My understanding as of a couple of weeks ago was that the initial implementation did not call the API directly from the browser, but this led to various significant unhappiness in the implementation. So we are planning to refactor such that the browser will make these calls directly. This will require some javascript development. I'm not sure who has been/will be tasked with that, or if any of that work has been started/completed.

Yes, it will be called directly from the browser.

The initial implementation exposed a proxy on with the exact same interface as on which just forwarded the calls to meta on the backend. That was done to avoid CORS and made absolutely no sense from any perspective, so the proxy has been removed. I'm working on supporting authenticated CORS for the API on meta.