What would be a typical workflow for, say, a standalone desktop Java application like https://github.com/yarl/vicuna ?

Suppose during first run the program requests the application key automatically via API.

The user then logs in, gets asked to login to the Wikimedia wiki to get an app-specific OAuth token.

Would they need to enable the application *and* get the token for it? Why do basically the same thing twice? (and that for every user)

I think that the user-deployed application or bot do not have the problem that OAuth is designed to solve - a potentially untrusted third party running the actual code on user's behalf.

For this use case I think that simple per-application, expiring, revocable API keys (like Github ones) should be sufficient....

Well actually for such an app I can use user_token and store it forever. Not very nice, but should work.

I originally intended this to have the functionality of the "Resource Owner Password Credentials Grant" flow of OAuth 2, which I think is the concept that bot (or desktop/mobile apps) would want. But doing that under OAuth 1 means jumping through a lot of hoops. But we can hack our way around most of the issues.

The big question is, how do we set things up so that it's difficult for a malicious desktop/mobile app to trick a user into granting highly privileged rights (like checkuser), when it claims to do something simple, like upload pictures to commons? If we say we simply don't care, then cool, let's just make it automatic. If we thing that we have a duty to make it difficult for a malicious person to do this, then it becomes really difficult.

I'm obviously of the opinion that we do have that responsibility, but if the community is generally in favor of letting people shoot themselves in the foot for the sake of convenience, then let's work towards the best solution under that assumption. Otherwise, you can totally implement this process right now via screen scraping and, a proxy, and a bot that has OAuth Admin privileges, so I'd rather come up with a method that people aren't fighting against.

In T87395#1765710, @csteipp wrote:

I originally intended this to have the functionality of the "Resource Owner Password Credentials Grant" flow of OAuth 2, which I think is the concept that bot (or desktop/mobile apps) would want. But doing that under OAuth 1 means jumping through a lot of hoops.

I might be missing the point of that protocol, but it does not seem to help against a malicious application at all: it would obtain the password, which is the worst possible situation. Also, if there is a non-malicious application with highly privileged rights, what's stopping a malicious application from identifying as that application once it has the password, and thus obscuring its trail? We want to ensure the user goes through the authorization dialog so they can be aware what rights they are granting.

Basically what we want is:

1. make the application go through the approval process (so that when nothing needs a checkuser grant on a given wiki, a desktop app cannot automatically register itself with that right), but only once, not separately for every single user
2. make the user go through an authorization dialog, so that it is clear what rights are given.

It seems to me that we don't need to do anything special, apart from supporting non-redirect-based communication: the developer registers the app, gets it approved, puts the secret key in the code, the app starts the normal OAuth grant flow, opens the auth dialog in a browser, but instead of redirecting we just display the token so the user can type it in.
That's somewhat insecure, but can you get any more secure than that with a desktop app? There is no way to prevent a malicious application from impersonating another without some form of trusted computing.

I came to conclusion that OAuth for desktop apps is just a bad idea. The user (fortunately!) controls the app and very often they can modify it as they see fit. So those apps should use standard API Login and cookies. That's what Python wiki bot is doing for example.
I have some idea how to make give the user a bit more fine-grained control, but this will be a separate bug.

For desktop apps you actually run from your desktop, sure. But they might be running in a "public" environment where the owner cannot prevent others from accessing the code. (I know some pywikibot operators who are refusing to move their bots to Tool Labs for that exact reason.) Not exposing your password / limiting the permissions of your bot that someone might take over makes sense there. Although not necessarily with OAuth, e.g. we could provide application-specific passwords like Google does.

Change 255488 had a related patch set uploaded (by Anomie):
Add owner-only consumers

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

Change 255488 merged by jenkins-bot:
Add owner-only consumers

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

https://www.mediawiki.org/wiki/Manual:Pywikibot/OAuth and https://www.mediawiki.org/wiki/Manual:Pywikibot/login.py#Login_using_OAuth should be updated once this is deployed.

Uh, I forgot completely that this involves a schema change. I'll take care of that on Monday.

Change 259052 had a related patch set uploaded (by Gergő Tisza):
Revert "Add owner-only consumers"

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

Change 259052 merged by jenkins-bot:
Revert "Add owner-only consumers"

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