@sdkim I have a few initial questions below for the API Gateway team. Apologies if I'm tagging the wrong PM!

Short description editing is currently broken in the app, and we're hoping to fix it via leaning on the new short description API. I have started on this spike to 1. generally see what it takes to implement oAuth2 in the app and 2. see if it's possible to only utilize it for short description editing, for a quicker and lower-impact fix.

1. It's my understanding that we'll be using the "User authentication" flow described here, including the PKCE code challenge for authenticating. This is the flow that takes the user through a web view for logging in so that the app doesn't know their credentials. Currently in the app our users log in through a native view, and we use this tokens API to log them in and get a csrf token for any data-modifying actions. My thinking (though I'd have to prototype to be 100%) is that we will have to switch authentication entirely in the app to oAuth2, not just piecemeal, otherwise they would need to log in twice - once the old way natively to get those tokens and the session cookies set, and again via the web view for oAuth for any new APIs we support. I did a sweep to see what all actions we have in the app that request a csfr token, and it seems we use it for both the MediaWiki Action API and some RESTbase APIs (note this isn't comprehensive):
   • adding a section to a page - POST https://en.wikipedia.org/w/api.php (action=edit&format=json&section=new&summary=new%20topic%20test&text=blah&title=User%20talk:Tsevener&token=39e5ae7174b49cce6ac748c7985f7d2b600f338e%2B%5C)
   • appending to a section - POST https://en.wikipedia.org/w/api.php (action=edit&appendtext=blah&format=json&section=5&title=User%20talk:Tsevener&token=ef35c9584df7cb311a6bbfbd3c2c6613600f340b%2B%5C)
   • upload new wikitext for a section - https://test.wikipedia.org/w/api.php (action=edit&format=json&section=0&summary=&text=blah&title=HelloWorld&token=45e36e1ea52e36b297338b8676bf0cbe600f34f5%2B%5C )
   • updating title description (note this can be replaced by the new short description API) - POST https://www.wikidata.org/w/api.php?action=wbsetdescription&format=json&formatversion=2 (id=Q1807798&language=en&token=ce26af505f742aaf12858fd324b9d184600f32e7%2B%5C&uselang=en&value=blah)
   • delete reading list DELETE https://en.wikipedia.org/api/rest_v1/data/lists/2931105?csrf_token=8a67d064d6cf593d468ac484bbe9dee1600f2663%2B%5C
   • remove entry from reading list DELETE https://en.wikipedia.org/api/rest_v1/data/lists/2931087/entries/28432700?csrf_token=c5be280af121666f94f7d9cd796930db600f260e%2B%5C
   • add entries to list POST https://en.wikipedia.org/api/rest_v1/data/lists/2931090/entries/batch?csrf_token=c1549620f3c060e8414073e80844e4a5600f2515%2B%5C
   • create lists POST https://en.wikipedia.org/api/rest_v1/data/lists/batch?csrf_token=704e0ca9f4fa318442810f9d7329be04600f246d%2B%5C
   • setup reading lists POST https://en.wikipedia.org/api/rest_v1/data/lists/setup?csrf_token=fd154ba2d03e548a7b356c78ad0c3f61600f1d80%2B%5C
   • thanking someone POST https://en.wikipedia.org/w/api.php (action=thank&errorsuselocal=1&format=json&rev=990042405&source=diff&token=25b85e39377b5000195bc92de6d908ce600f26ad%2B%5C)

My first question is - are these MediaWiki and RESTbase APIs supported with oAuth2 authentication? Also, I may be conflating login and API authentication but how does account creation, 2FA, and password reset fit with this flow? If we remove the native login flow will we need to remove those native flows as well?

2. I found a couple of different documentations on setting up API keys. One is within the API portal dashboard and another is in mediawiki.org at this consumer registration form. If the app makes calls to both api.wikimedia.org and MediaWiki action endpoints, does this mean we have to register a key in both places, and does that mean a change for the login web flow? Or do we wait for all data-modifying APIs that we call via MediaWiki to be implemented in api.wikipedia.org so that we just have a single API key?

3. How are we allowing anonymous users to edit with this new system? The short description edit/delete API seems to suggest that the authorization code is a must.

Ccing @JMinor @Dbrant for more 👀 and any thoughts/concerns they may have.

My first question is - are these MediaWiki and RESTbase APIs supported with oAuth2 authentication?

MediaWiki - yes, they should support logging in via OAuth. REST API in Mw bypasses CRSF tokens requirement if the session is safe against CSRF (which OAuth authenticated session is), but action API doesn't have this optimization now. We can add it if Security team gives us their blessing.

RESTBase - no. We only pass through the cookie, but nothing really prevents us from passing through the Authentication header. this would be a dirty quick fix. Better way of doing it would be to move the reading list API into MW core rest API and expose it via the gateway. See T264668 - that will also move us closer to RESTBase sunset, so it's a win-win.

2. If the app makes calls to both api.wikimedia.org and MediaWiki action endpoints, does this mean we have to register a key in both places, and does that mean a change for the login web flow? Or do we wait for all data-modifying APIs that we call via MediaWiki to be implemented in api.wikipedia.org so that we just have a single API key?

No, keys registered in either place work for all endpoints that support OAuth 2. However, there is one caveat: the API Portal form offers a simplified set of permissions compared to the Meta-Wiki form. If you need permissions beyond what is listed here under basic, createeditmovepage, and editprotected, you'll need to use the Meta-Wiki form. Either way, you should be able to use a single key for all endpoints that support OAuth 2. Does this help answer "does that mean a change for the login web flow"?

3. How are we allowing anonymous users to edit with this new system? The short description edit/delete API seems to suggest that the authorization code is a must.

The API Gateway endpoints require some form of OAuth authentication for write requests. This can work using the app authentication flow, but I don't believe that flow is intended to be used by mobile apps because of the security policy. (Selecting non-confidential/mobile app when creating a key disables the app authentication flow.) But clearly we need to be able to do anonymous editing, so maybe someone else can help answer this. (There's some history related to this in T256769.)

One extra step to consider: Once you've created your OAuth key, it should probably be added to the internal tier to get a higher rate limit for API Gateway endpoints. It's likely that someone on Platform Engineering could help with this.

@Pchelolo @apaskulin @sdkim yep that answers most of my questions, thanks for clearing that up!

I did have one last buried question in there about how our native account creation, password reset, captcha, & 2FA-type actions would work with this new setup. Here are some the related calls that we make for those in case that helps with digging on your end:

Form field calls

This looks like a pretty flexible endpoint that tells us which fields to ask the user. Generally it's a username and password field, but it can also give us captcha information like IDs.
POST https://en.wikipedia.org/w/api.php Body: action=query&amirequestsfor=login&format=json&meta=authmanagerinfo
POST https://en.wikipedia.org/w/api.php Body: action=query&amirequestsfor=create&format=json&meta=authmanagerinfo

Retrieving a Captcha image
https://en.m.wikipedia.org/w/index.php?title=Special:Captcha/image&wpCaptchaId={{captchaID}}

Retrieve tokens for performing certain actions

POST https://en.wikipedia.org/w/api.php Body: action=query&format=json&meta=tokens&type=login
POST https://en.wikipedia.org/w/api.php Body: action=query&format=json&meta=tokens&type=createaccount

Login call with Captcha
Note: looks like this could return a pass and fail flag, and followup additional fields to setup a new password if you logged in with a temporary one from the reset password flow.
POST https://en.wikipedia.org/w/api.php Body: action=clientlogin&captchaId={{captchaID}}&captchaWord={{captchaWord}}&format=json&loginreturnurl=https://www.wikipedia.org&logintoken={{loginToken}}&password={{password}}&rememberMe=1&username={{username}}

Create account call with Captcha

POST https://en.wikipedia.org/w/api.php Body: action=createaccount&captchaId={{catpchaID}}&captchaWord={{captchaWord}}&createreturnurl=https://www.wikipedia.org&createtoken={{createToken}}&email=&format=json&password={{password}}&retype={{password}}&username={{username}}

Call that triggers reset password email to be sent
POST https://en.wikipedia.org/w/api.php Body: action=resetpassword&format=json&token={{emptyToken}}&user={{username}}

I don't have a 2FA account so I don't have details on that yet, I can look into getting one if needed though.

Just an update - I'm happy to continue discussing this spike further, but for now I'm switching to other things. @JMinor will discuss with @sdkim next week on where we landed.

The spike here is complete, but I'm leaving open for future reference when we move to implement the API in future.

See https://phabricator.wikimedia.org/T407525 for LOE and writeup.