Right now, if an OAuth consumer wishes to add or remove grants that their application needs, they have to go through the approvals process again as a separate application. Consumers should have a way to update the grants for their application without having to do essentially create it as a new application.
See also: T59631.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T103587 Improve OAuth application approval workflow | |||
| Open | None | T62380 OAuth developers should be able to change what grants their application asks for instead of having to submit a new application |
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?