Wikimedia API Portal wiki is intended to serve as a central knowledge hub for developers using Wikimedia APIs. Additionally, the portal would provide the ability for developers to manage credentials for their registered OAuth consumers. The consumer management is being implemented in WikimediaApiPortalOAuth extension.
WikimediaApiPortalOAuth extension will be enabled on api.wikimedia.org. The extension provides client-side interface to manipulate OAuth consumers. REST API is being added to the OAuth extension, exposing CRUD operations for OAuth consumers. This capability will be only enabled on the OAuth central wiki (meta.wikimedia.org) since on the database level the consumers are only stored on central wiki, and cross-tenant writes is not well supported in MW - e.g. it would be extremely hard to expose the oauth consumer CRUD API on any wiki other then central wiki, since we lack a bunch of necessary abstractions in core to safely execute the code in the context of another wiki.
In the patch linked above it's implemented by exposing proxy api on the portal wiki, and copying the user's cookie over, and calling central wiki over HTTP from the app server. This is done to avoid a CORS request from portal wiki to the central wiki. I do not think the reasons why this is pretty horrific need to be listed.
Instead, we intend to make authenticated CORS requests from api.wikimedia.org to meta.wikimedia.org.
- On meta.wikimedia.org, ONLY for the required oath consumer CRUD endpoints, set Access-Control-Allow-Credentials: true. According to the spec, for CORS requests with credentials, Access-Control-Allow-Origin must be an exact match, so we would 'hardcode' it to api.wikimedia.org to restrict usage of consumer CRUD API to a single use-case.
- The fronted code from api.wikimedia.org will set withCredentials on the Ajax request to meta.wikimedia.org, and will include the central auth cookies.
This theoretically should just work (TM), however I'm interested in any potential security concerns with this approach.