Page MenuHomePhabricator

Improve OAuth application approval workflow
Open, HighPublic


High-level task for tracking tasks related to a more convenient/flexible approval system.

Related Objects


Event Timeline

Tgr created this task.Jun 23 2015, 7:31 PM
Tgr raised the priority of this task from to Needs Triage.
Tgr updated the task description. (Show Details)
Tgr added a subscriber: Tgr.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 23 2015, 7:31 PM
Tgr added a project: Epic.Jun 23 2015, 7:54 PM
Tgr triaged this task as Medium priority.Jun 29 2015, 7:08 PM
Tgr set Security to None.
Tgr added a comment.Sep 9 2016, 1:51 AM

After thinking about it a bit I think a better workflow would look something like this:

  • "under development": this is the initial state for new consumers. Invisible for everyone but the owner (and maybe OAuth admins); works for the owner but does not work for anyone else (like the "proposed" state currently). All properties are freely editable. (This means dealing with the case when grants are edited and the owner already did the authorization; but since it's only for testing at this point, it should be fine to just delete the authorization.) The owner can move it to "proposed" state (which sends a notification to OAuth admins).
  • "proposed": visible to everyone but only works for the owner. Cannot be edited anymore (to avoid race attacks). OAuth admins can move it back to under development (to ask for description changes etc) or "approved" or "rejected" state.
  • "approved": visible and works for everyone, cannot be edited. Owner and admins can move to "disabled".
  • "disabled": visible for everyone, works for no one (or maybe the owner only, for debugging?). Cannot be edited. Admins can move to "approved" (maybe "rejected" too?).
  • "rejected": visible for everyone, works for no one, cannot be edited. Admins can move to "approved".
  • "expired": I think we can kill this state and the concept of proposal auto-expiration. Existing expired records would be turned into to "rejected".

"Cannot be edited" means most fields cannot be edited. Usage restrictions and the RSA key are always editable and the secret can always be regenerated. The owner is always the only one who can edit.

When disabling or rejecting, the consumer can also be suppressed if the user has the rights (this is same as the current behavior).

As currently, the owner would be notified of every state change unless they performed it themselves.

This would take care of T60937: Add "under development" stage before "proposed" stage for OAuth consumers, T65712: OAuth: Developers should be able to revoke their own tool's approval, and the most painful part of T59631: OAuth developers should be able to change some of the parameters they registered an application with instead of having to submit a new application, while avoiding the troubles associated with modifying a consumer which has already been authorized by some users.

Tgr raised the priority of this task from Medium to High.Mar 7 2017, 3:57 AM
Tgr moved this task from Backlog to UI/UX on the MediaWiki-extensions-OAuth board.