I just want to note here that if we allow people to update the grants on their OAuth consumer, we'll need to give all users who have approved that consumer on their account a reconfirmation dialogue, so that they're aware that the consumer's granted rights have changed and that it applies to their account.

Can we actually trigger a reconfirmation dialog in that situation, and will client applications know how to handle it? Or would we just revoke the auth token and let the client treat it as a revocation?

When the end user authorizes the consumer, it saves the list of grants that the end user actually authorized. So it *should* work that the consumer would continue to be granted only the old set of permissions until such time as the it sends the end user through the authorization page again and the end user re-authorizes.

(In reply to comment #3)

When the end user authorizes the consumer, it saves the list of grants that
the
end user actually authorized. So it *should* work that the consumer would
continue to be granted only the old set of permissions until such time as the
it sends the end user through the authorization page again and the end user
re-authorizes.

On a personal level this is the work flow that I'd like the most but I can certainly see arguments for trying to force it.

When an application asks for different grants than the ones it was approved for, it should most definitely go through the approvals process again. Otherwise I can register an application that asks for basic rights and claims to do something simple, then start asking for sensitive grants like viewdeleted or editinterface, and hope that some users don't notice and click through.

I take it this task is about the ability to change grants and get those changes approved, instead of having to register a new application. Which means we would have to store both the approved state and the pending state.

We already store the set of rights that a user approved on their authorization, in case we ever wanted to do this. So correct, the work would be on the consumer, tracking the current rights and a requested set of new rights.

Changing the callback url is the most common reason to re-approve an app, so might be good to address that as the primary case, and see if this can be fit into the same model?

Hm, should this be prioritized more? It is 8 years now.

@Mitar: Please feel free to work on this so it becomes more of a priority. :) Age of a ticket does not influence relevance or urgency. Thanks!

The extension is not actively developed, so prioritization largely means finding someone to spend free time on it. Not very likely for something as complex as this task.

The monster patch in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/OAuth/+/316302 tries to address part of this (changing things before the grant is approved), but a single huge patch was an unwise approach to getting things changed in an extension that's not under active maintenance, so it would have to be reworked into something more granular.

As for changing approved consumers, seems to me like a lot of work for something that's not very different from the current workflow of just registering a new consumer. Maybe we could have a "create a new version of this consumer" link instead, which would pre-fill the form.

I was interested in this primarily for my own self-approved app used only by me. There it should be trivial to just change grants.

But yea, afterwards I figured out that I can just create a new app with same name just different version, which seems a pretty OK workaround. So maybe it should be clearer in text somewhere that you can reuse same name, just use different versions.

In T62380#7863739, @Mitar wrote:

I was interested in this primarily for my own self-approved app used only by me. There it should be trivial to just change grants.

That's T142274: Changing grants for owner-only permissions should be easier. Implementing it isn't entirely trivial though. The management UI has no concept of changing a consumer currently. That would have to be added, with appropriate permission management, plus automatic update of the consumer acceptance record.

Thanks for linking to that task.