Page MenuHomePhabricator

Allow more flexibility in what permissions are authorized
Open, NormalPublic

Description

Currently an app must list all permissions it might conceivably need and the user must grant them all together. This has some usability and privacy/security disadvantages:

  • seeing a huge list of requested rights is confusing, when most of those are out of context (not needed for the current activity)
  • seeing requests for rights the current user does not have is confusing (see also T94478)
  • a privacy/security-conscious user might want to refuse some rights at the cost of losing some non-essential functionality; right now that is not possible

There should be a way to only request or only grant a subset of all rights the application is capable of using.

Details

Reference
bz57505

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 2:13 AM
bzimport set Reference to bz57505.
bzimport added a subscriber: Unknown Object (MLST).

Presumably the reason why a user would want to revoke some permissions during the initial authorisation is because the application is asking for more than the user expected. If the application was not asking for more than it needed but it's just that the user isn't aware of what the application really needs, then we've just let the user break the application's functionality right at the first step, which isn't good. On the other hand, if the application was actually asking for more than it needed, then the OAuth admins failed to vet the initial request from the consumer properly, which means the real problem was caused way before the user sees the authorisation request.

I'm open to being convinced for the need for this, but right now I'm not seeing the reason for this. I don't want to add in something that only patches up a problem caused elsewhere.

Some (read as "my") applications have too many features and normal users coming for some specific purpose never use all of them. However power users (read as "myself") use them so my application must request many permissions, because power users can't give that application more permissions than what it requests.

Maybe another resolution is to turn "Applicable grants:" into "Permissions requested by default", and allow granting permissions from user side, in addition to just revoking permissions.

This was actually the intended feature originally, but the UX team asked us to simplify the /authorize screen, including not doing this feature when we brought it up once. We could probably get away with adding an "Advanced" option that takes power users to an /authorize screen with more options though.

Liangent's particular use case is probably not the best use of this, however. In general, it would be best to design different versions of the bots for the major categories of different users, and each bot would have its own OAuth Consumer key.

Similar to Liangent's idea of allowing apps to add permissions, another feature that has been requested for a while is to make it possible for Consumers to upgrade the rights, and have a better UX for doing this. That's why we have the Consumer version number set by the app developer. The flow would probably look something like:

  • The Consumer would send the user back to /authorize
  • We see the user has already authorized a previous version of this Consumer
  • We prompt the user that <app name> would like "more permisssion" (or something like that), showing them the added and removed grants
  • User grants the new set of permissions, and we automatically revoke the old authorization
Deskana lowered the priority of this task from Low to Lowest.Mar 6 2015, 10:24 PM

This is definitely not going to be tackled any time soon.

Tgr renamed this task from Allow revoking some permissions on initial authorization to Allow more flexibility in what permissions are authorized.Jun 23 2015, 8:03 PM
Tgr updated the task description. (Show Details)
Tgr set Security to None.
Tgr added a subscriber: Tgr.Jun 24 2015, 12:54 AM

Made this more general. I think the best way forward is to allow applications to request any subset of the grants it has registered for. We already store right grants individually so that would not require changing the acceptance table, but the list of grants would somehow need to be included in the request, and the request should automatically succeed if a superset of those rights is already granted. That way the application could request the fundamental rights first, and additional rights in context once they are actually needed. That's the direction mobile apps are moving towards as well.

Leaving the selection of which individual grant to refuse to the user is a bad idea, since that would require the app to gracefully handle all failure scenarios arising from grant combinations that don't really make sense and make the application unable to perform its basic function; that kind of error-handling code would probably not get much attention.

That sounds sane to me

Tgr raised the priority of this task from Lowest to Normal.Jun 29 2015, 11:57 PM
Viztor added a subscriber: Viztor.Jul 18 2019, 2:52 AM

any update on this?

Tgr added a comment.Jul 18 2019, 9:13 AM

any update on this?

OAuth is not resourced currently. Changes happen whenever someone has free time (and nothing more important to do with it).