OAuth 1.0 does not support clients without a backend component, sadly (as they have no way to keep the consumer secret secret). See #5 of the review guidelines.

You can use owner-only OAuth to authenticate without passwords, but the setup process is very user-unfriendly at the moment.

Who did you talk to about WMF login requirements?

This was a conversation between the Legal team, as well as the Android team at WMF. The Legal team has recommended that the Commons app should implement OAuth, if they want to continue to have their app distributed through the WMF's Google Play Store account (and continue to use the Wikipedia / Commons branding). Otherwise, they would need to move the app into their own separate Play Store account.

To be honest, I was actually confused about this myself. Our own Wikipedia Android app itself doesn't use OAuth yet, and it's not really clear to me how we could implement it without a backend component, so I don't know how else we can help the Commons team with this issue.

That seems like a strange requirement. If the app uses the WMF account, the WMF can see what code is being uploaded and it can verify that the passwords are not being collected even though the app has access to them. If it uses a separate account, there is no way to make sure, so it seems strictly worse from a security standpoint.

Anyway if you don't want to give the app access to the passwords (which is definitely how it should be in an ideal world) these are the alternatives I can think of:

• Use owner-only OAuth (basically four 30-40 character random tokens instead of username + password which you would use to sign API requests). The usability is kind of crap: the user has to be autoconfirmed, has to navigate through a scary-looking form that was really meant for developers, pick what permissions they need, then copy long random strings into the app config somehow. (See T142279, T165219, T142317, T142274 for some suggested improvements, but note that the WMF has not resourced OAuth work for a long time.)
• Write a server-side component that signs requests and forwards them to Commons. The app would store the access token and secret, the server would store the application token and secret.
• Tell users to use bot passwords. No change needed on your side (apart from handling errors from bot passwords with overly restrictive grants); some users would probably misunderstand and provide real passwords anyway, though.
• As above, but add a parameter to the login API that asserts the user is logging in with a bot password (trivial), and use it in the app. This won't prevent users from entering their real passwords (so not much of a change from a treat-the-app-as-potentially-malicious security POV) but at least they would get an error and would have to replace if with a safe password.

We made some progress with the OAuth implementation using android-oauth-library that @Fjalapeno WPF suggested.

Am now stuck at some E006 error. This seems to be related to issues other have run into while using OAuth on mobile T74186 and T119343. My suspicion is that it might have to do something with redirection to mobile version of wiki URL. See WIP PR

Any help with it would be really great. :)

Attached screenshot for ref.

Also attached app logs for more context.

I’m adding @Anomie here who has a lot of insight into authorization in MediaWiki
Brad, do you have any insight into the issue here? Seems like that code is pointing to an invalid OAuth Key

@Tgr just to follow up on your comment on the need to use OAuth: The requirement comes from legal... basically as way to remove the liability of being responsible for handling user credentials.

Is there a chance to have another dicussion with them that involves someone who understands how OAuth works? :)

E006 means that they key you supplied isn't found in the database. It's possible it's the redirect as described in T74186#750517. Assuming things haven't changed since then, apparently you might need to use /wiki/Special:OAuth/authorize while using /w/index.php?title=Special:OAuth for any signed request.

Or it could be that the key you're using is incorrect somehow.

My consumer request had already been declined. Just to confirm that E006 isn't coming because of this, i made a new consumer request. I am getting the same error with that too.

Also as suggested by @Anomie i tried using /wiki/Special:OAuth/ instead of /w/index.php?title=Special:OAuth but still the same error.

These are the URLs that I am trying.

Set 1

As suggested by @Anomie

Token request URL: https://en.wikipedia.org/wiki/Special:OAuth/initiate
Auth verifier URL: https://en.wikipedia.org/wiki/Special:OAuth/authorize

Set 2

As documented on https://m.mediawiki.org/wiki/Special:MyLanguage/OAuth/For_Developers

Token request URL: https://en.wikipedia.org/wiki/index.php?title=Special:OAuth/initiate
Auth verifier URL: https://en.wikipedia.org/wiki/Special:OAuth/authorize

If anyone could point out to any android/mobile application that is currently using wikimedia OAuth will be very helpful.

Rejected consumers would result in E005, not E006, I think.

I'm not sure what I said earlier really registered... there are no mobile applications using OAuth because mobile clients are incompatible with the OAuth 1.0 security model, so such applications will never be approved.

Thanks @Tgr for your reply. Then I guess @Fjalapeno can confirm if there's any need to continue with this task. WMF's legal team can probably connect with WMF tech people to align themselves on the challenges.

@Fjalapeno Hey! Do you have any pointers for us?

Update to all: After some discussion, we have been informed that this requirement has been waived, for the reasons mentioned here. Thank you for your patience and help, everyone. :)

Shall we close this task?