I'm not sure what the rationale for having a manual approval process is/was.

The Wikimedia stewards are generally very responsive... so I have a feeling that stewards may not yet be in charge of approvals? Or perhaps the queue isn't visible enough.

The slow approval process definitely sounds like there's a bug somewhere, though.

We made the decision to have the approval process at first because we weren't sure how it was going to be used, and what way we would need to extend the protocol (for example, Twitter still requires an approval process to us xAuth). We certainly discussed not having approvals in the future. Or having the application send a notification to the admins.

We can certainly add a feature flag for it the applications should be approved or not (Patches welcome. Adding features is something I do in my spare time, which I haven't had any of in a while). I'd like to finish turning the process over to the stewards and make sure that's what they want before flipping the switch though.

*poke*

Or having the application send a notification to the admins.

That's T61772.

Maybe we should have a feature flag that maps grants to approval required/not required. E.g. we probably don't want to require approval for authentication only apps, and maybe not for simple editing/uploading either. We probably want approval for access to private data and for admin-level stuff.

@dpatrick what do you think?

We discussed this in the weekly Security Team meeting. We came to no consensus. We discussed a few alternatives:

• automatic approval;
• automatic approval for a "general" class of applications, with an interstitial message indicating that the app in question has not been approved/reviewed; additional manual approval for an "approved" class of applications, which an OAuth admin has reviewed; and
• a beta feature which, when enabled, allows access to unreviewed OAuth apps.

We discussed some of the the problems with the current review process -- that there are few community members who are interested in participating, that there is no way to ensure that the consumer is not modified after the review has been completed/there is no subsequent review to ensure an OAuth app is still behaving safely, etc.

For the time being, @Bawolff and I will keep and eye on the queue and work on approving requests. Additionally, we'd like to figure out some way to have notifications of the appearance of new requests, and could use some help on that.

Hi @dpatrick. Thanks for the update. Could you post some of the arguments against approving OAuth consumers by default? It seems that the only arguments discussed in your posts are call attention to how the current review process does not serve many of the needs we hoped it might.

I note that, since this task was filed, the process for approvals seems to have moved to the Stewards at https://meta.wikimedia.org/wiki/Steward_requests/Miscellaneous. We also now have owner-only consumers which are automatically approved.

In T67750#2455145, @Halfak wrote:

Hi @dpatrick. Thanks for the update. Could you post some of the arguments against approving OAuth consumers by default? It seems that the only arguments discussed in your posts are call attention to how the current review process does not serve many of the needs we hoped it might.

The most compelling concerns (imho) were in regards to oauth being used as part of a phising attack.

In T67750#2455206, @Anomie wrote:

I note that, since this task was filed, the process for approvals seems to have moved to the Stewards at https://meta.wikimedia.org/wiki/Steward_requests/Miscellaneous. We also now have owner-only consumers which are automatically approved.

The app registration page indicates that there is no standard procedure for approving OAuth consumers and references the RfC. My understanding, based on the talk page on the RfC, was that stewards weren't actively reviewing app proposals. However, having just looked at rejected requests and mwoauthconsumer log, I see that @MarcoAurelio, @Ajraddatz and others have been active in reviewing proposals. So I may have been incorrect in that assumption.

Is my understanding of the state of the hand-off process incorrect?

In T67750#2455145, @Halfak wrote:

Hi @dpatrick. Thanks for the update. Could you post some of the arguments against approving OAuth consumers by default? It seems that the only arguments discussed in your posts are call attention to how the current review process does not serve many of the needs we hoped it might.

Hi @Halfak. In line with what Gergõ described on the talk page and in the RfC, I'm interpreting that there needs to be some party responsible for verifying that OAuth apps:

• Adhere to our privacy policy, since those apps function to increase the area of privacy concern beyond code that we create and (ostensibly) audit; and
• Behave in ways that do not abuse any advanced rights granted them (e.g., Upload new files, Block and unblock users, Send email to other users, etc.).

I think it's okay to auto approve "Authentication only, no API access" registrations (T67750#1764333), in addition to owner-only consumers (T67750#2455206).

In T67750#2465051, @dpatrick wrote:

In T67750#2455206, @Anomie wrote:

I note that, since this task was filed, the process for approvals seems to have moved to the Stewards at https://meta.wikimedia.org/wiki/Steward_requests/Miscellaneous. We also now have owner-only consumers which are automatically approved.

The app registration page indicates that there is no standard procedure for approving OAuth consumers and references the RfC. My understanding, based on the talk page on the RfC, was that stewards weren't actively reviewing app proposals. However, having just looked at rejected requests and mwoauthconsumer log, I see that @MarcoAurelio, @Ajraddatz and others have been active in reviewing proposals. So I may have been incorrect in that assumption.

Is my understanding of the state of the hand-off process incorrect?

I just know that the stewards have been approving consumers, as you saw, and that the requests seem to be happening on that page. I haven't seen anything where anyone formally said that the hand-off happened, though.

I set up the mediawiki message directing people to SRM. Stewards have the technical ability to approve OAuth customers, but have been hesitant to do so and the full "hand-over" still has not happened. But we are helping to approve some requests from trusted sources to reduce the backlog.

@dpatrick, OK. Looks like this is *wont fix*, so I'm unsub'd.

Could we reboot this discussion, at least to allow auto-confirmation of read-only access of private content? I ran into this problem during the hackathon - wanting to setup an oauth account. My use case is for local development purposes - I would like to be able to query production APIs to access content such as watchlist and preferences in read-only mode.

You should be able to use an owner-only consumer for that.

Also, the owner of a (non-owner-only) consumer can use it while it's in the "proposed" state, intended for development and debugging.

I think that @Tgr and I are functionally the only active OAuth admins at metawiki these days. There are others with the right, but per https://meta.wikimedia.org/w/index.php?title=Special:OAuthManageConsumers/approved&offset=&limit=500 the only other person approving in the most recent 500 actions was Magnus self approving some grants. As a "last person standing" on this at the moment, I would be interested in the system auto approving:

• https://127.0.0.1:*
• https://localhost:*
• https://[::1]:*
• ident only grants
• ident + email grants
• "basic rights" grants

This would actually cover a reasonable percentage of our current request traffic. These are also the things that I am manually approving without really any deeper consideration.

At a software level the right thing to do is probably to add setting(s) to describe what the system should auto approve and leave the actual policy implementation up to the individual OAuth server deployment rather than holding the entire MediaWiki community hostage to the concerns of the Wikimedia project wikis. For what I have describe above I think that two settings would suffice:

• $wgOAuthAutoApproveUrlRegex - auto approve any request which matches this regex
• $wgOAuthAutoApproveGrants - auto approve any request where all requested grants are in the auto approve list

With this combination a service could be configured to auto approve nothing, everything ($wgOAuthAutoApproveUrlRegex = '/^.*$/';), or selective sets like the one I am currently interested in.

This would not cover a desire to auto approve only when both the URL pattern and grants are within set limits. There are a few different ways of varying complexity I can think of to allow that as well. One possibility would be an array keyed by URL regex with grant list values. In that implementation an empty grant list could be treated as "any grants" to enable using a single configuration setting to cover both:

$wgOAuthAutoApprove = [
    '#^https://(127.0.0.1|\[::1\]|localhost)(:\d+)?(/.*)?$#' => [],
    '#^.*$#' => [ 'authonly', 'authonlyprivate', 'basic' ],
];

I am unsure about the security implications of auto-approving localhost apps. For OAuth 1 I think it would mean if an attacker can acquire any port on the victim's computer (via malware, tricking them into setting up a tunnel etc) they can create a consumer with sensitive grants and some misleading name/description, and extract a request token. For OAuth 2 it's even easier, it can just be a page on a local webserver (e.g. ask the victim to test a MediaWiki patch, have that patch include a web page that acts as a client). I think the way to go for localhost test apps is T60937: Add "under development" stage before "proposed" stage for OAuth consumers. At the very minimum it should be restricted to not particularly dangerous grants.

Auto-approving ident-ish grants sounds good, we should probably get a nod from Security-Team.

I can see a potential use case for URL-based auto-approval: we might be more relaxed with Wikimedia Cloud URLs as the target domain and hardware is under our own control. (E.g. we could auto-approve anything that doesn't need admin rights.) YAGNI for now but maybe reason enough to prefer $wgOAuthAutoApprove over $wgOAuthAutoApproveGrants. I'd go with an extensible syntax like

$wgOAuthAutoApprove = [
    [ 'grants' => [ 'authonly', 'authonlyprivate', 'basic' ] ],
    // can later be extended with something like
    // [ 'domain' => [ '*.toolforge.org', '*.wmcloud.org' ], 'grants' => [ 'edit' ] ],
];

In T67750#8784304, @Tgr wrote:

I am unsure about the security implications of auto-approving localhost apps. For OAuth 1 I think it would mean if an attacker can acquire any port on the victim's computer (via malware, tricking them into setting up a tunnel etc) they can create a consumer with sensitive grants and some misleading name/description, and extract a request token. For OAuth 2 it's even easier, it can just be a page on a local webserver (e.g. ask the victim to test a MediaWiki patch, have that patch include a web page that acts as a client).

Other than when all/nearly all grants have been checked I have been approving functionally all localhost targeted consumers for years. I agree that there are lots of ways to imagine abuse of network-connected authn/authz protocols, but I do not agree that human judgement is likely better than a codified rule set enforced by software.

At the very minimum it should be restricted to not particularly dangerous grants.

I know I invented one of the scariest, Access two-factor authentication (OATH) information for self and others, so that Striker & Horizon could require use of 2FA tokens when enabled for the Developer account at wikitech. I think it would be helpful for discussions like this one to enumerate which exact grants we each see as potentially dangerous. For me, I think that list is:

• Edit your user CSS/JSON/JavaScript (editmycssjs)
• Edit your user preferences and JSON configuration (editmyoptions)
• Edit the MediaWiki namespace and sitewide/user JSON (editinterface)
• Edit sitewide and user CSS/JS (editsiteconfig)
• View deleted files and pages (viewdeleted)
• View restricted log entries (viewrestrictedlogs)
• Hide users and suppress revisions (oversight)
• View your watchlist (viewmywatchlist)
• Edit your watchlist (editmywatchlist)
• Send email to other users (sendemail)
• Create accounts (createaccount) (because it includes the tboverride-account and override-antispoof rights when granted to the user)
• Access checkuser data (checkuser)
• Manage global account status (setglobalaccountstatus)
• Manage your OAuth clients (oauthmanageownclient)
• Access two-factor authentication (OATH) information for self and others (oath)

I didn't put those in any particular order. I just read the table at https://meta.wikimedia.org/wiki/Special:ListGrants from top to bottom and listed them as I found them. I think they largely fall into these categories:

• rights that allow changing how an individual account functions (css, js, options)
• rights that allow changing how things function for everyone on a wiki (interface, site config)
• rights that allow viewing/modifying restricted content (my watchlist, logs, suppressed, CU)
• rights that allow non-public communication (email)
• rights that allow changing authentication/authorization (account creation overrides, account oauth client management, oath)

In T67750#8786893, @bd808 wrote:

I do not agree that human judgement is likely better than a codified rule set enforced by software.

It's hard to codify "seems like this is trying to impersonate a popular tool". In any case, I don't really like the existing practice either. As I said, I would rather push for T60937: Add "under development" stage before "proposed" stage for OAuth consumers.

I think it would be helpful for discussions like this one to enumerate which exact grants we each see as potentially dangerous.

See T290790: Group OAuth grants by riskiness, I'll follow up there.

In T67750#8787547, @Tgr wrote:

In T67750#8786893, @bd808 wrote:

I do not agree that human judgement is likely better than a codified rule set enforced by software.

It's hard to codify "seems like this is trying to impersonate a popular tool". In any case, I don't really like the existing practice either. As I said, I would rather push for T60937: Add "under development" stage before "proposed" stage for OAuth consumers.

I understand how an "under development" stage would help the human review tedium problem unless the assumption is that most people would never mark things for approval? The majority of recent grant requests that stick in my brain are OAuth2 grants asking for "basic rights" with completely random websites as the application. I have a hunch this activity is in part caused by some poorly written docs somewhere on how to start using the MediaWiki REST APIs, but irregardless this is why I bothered to come and try to perform necromancy on this ticket.

There is no reason to request approval of a localhost app, unless I am misunderstanding what they are for. The owner can test with their own account while it's in the development stage, and others are unlikely to want test it. (If it's something that's run locally but many different people will use it, ie. the app secret is public, such as a demo / tutorial app, then I think it's worth passing through human review because we want to make sure that's clearly documented. But I don't think that happens often.) Hopefully people would realize in the development stage that whatever they want to do doesn't work and not push further. (There could be language to that effect, to please make sure it works before requesting approval.)

There might be non-test apps which use localhost, where the tool is packaged as a web app that runs on your machine on some random port and you interact with it via the browser; but those would need review just as much as any normal web app.

In T67750#8787897, @Tgr wrote:

Hopefully people would realize in the development stage that whatever they want to do doesn't work and not push further. (There could be language to that effect, to please make sure it works before requesting approval.)

Humans as a general class do not read documentation. This has been proven repeatedly in our projects as well as the rest of the technical world.

There might be non-test apps which use localhost, where the tool is packaged as a web app that runs on your machine on some random port and you interact with it via the browser; but those would need review just as much as any normal web app.

Would they get that review today? As soon as I see "localhost" or "127.0.0.1" the only other thing I look for is OATH and CU rights in the requested grants.

Change 910806 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/OAuth@master] Auto-approve consumers with authentication-only grants

https://gerrit.wikimedia.org/r/910806

Change 910815 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[operations/mediawiki-config@master] OAuth: Do not require approval for read-only grants on public wikis

https://gerrit.wikimedia.org/r/910815

In T67750#8787924, @bd808 wrote:

Humans as a general class do not read documentation. This has been proven repeatedly in our projects as well as the rest of the technical world.

My rough idea of how to handle that is T159789: Include information about OAuth app review process and criteria into the interface.

Would they get that review today? As soon as I see "localhost" or "127.0.0.1" the only other thing I look for is OATH and CU rights in the requested grants.

I understand that is the status quo. I still think we should improve it.

Change 910806 merged by jenkins-bot:

[mediawiki/extensions/OAuth@master] Auto-approve apps with authentication-only grants

https://gerrit.wikimedia.org/r/910806

Let's deploy this this week. (It will only work after the train reaches group 1 but no harm in setting the config flag before that.)

Suggested Tech News text:

New OAuth apps go through manual review. Starting this week, apps using limited grants will not require review. (1)

The exact set of grants not requiring review will probably change so not sure if it's worth mentioning them. If it is, the news item could say apps using identification-only or basic grants instead.

Removing Community-consensus-needed - as @bd808 said few people have taken interest in the app review process and they (us) have been involved in the discussion here, and the change has Security approval.

(Rewrote the task description to match the current agreement - the original proposal of exempting all consumers from review pretty clearly did not have support.)

Change 910815 merged by jenkins-bot:

[operations/mediawiki-config@master] OAuth: Do not require approval for read-only grants on public wikis

https://gerrit.wikimedia.org/r/910815

Mentioned in SAL (#wikimedia-operations) [2023-05-02T07:40:40Z] <tgr@deploy1002> Started scap: Backport for [[gerrit:910815|OAuth: Do not require approval for read-only grants on public wikis (T67750)]]

Mentioned in SAL (#wikimedia-operations) [2023-05-02T07:42:05Z] <tgr@deploy1002> tgr: Backport for [[gerrit:910815|OAuth: Do not require approval for read-only grants on public wikis (T67750)]] synced to the testservers: mwdebug2001.codfw.wmnet, mwdebug2002.codfw.wmnet, mwdebug1002.eqiad.wmnet, mwdebug1001.eqiad.wmnet

Mentioned in SAL (#wikimedia-operations) [2023-05-02T07:48:19Z] <tgr@deploy1002> Finished scap: Backport for [[gerrit:910815|OAuth: Do not require approval for read-only grants on public wikis (T67750)]] (duration: 07m 39s)

@Tgr Much thanks for the draft! I've tweaked it slightly because the term "grants" is ambiguous and confusing jargon (especially within Wikimedia contexts!). I've written it as:

• All new OAuth apps go through manual review. Starting this week, apps using identification-only or basic authorizations will not require review.

If that needs to be further tweaked, please do so directly.
E.g. Perhaps it could have an additional sentence such as "This will make it easier for developers to make new or updated tools available to everyone." or something else about the intent? (It's not needed, 'twas just a thought.)
Thanks again!