Page MenuHomePhabricator

Support a more user friendly "re-authentication" flow for returning users
Open, LowPublic

Description

Split from T74654#1073751 where @csteipp wrote:

Since we know the consumer_id passed in, we can see if the user already has an authorization for that consumer. If so, we could present an entirely different, "reauthorization" form to the user which says they've given access previously with a button to revoke the access or (if the request token is valid, so not the case that this bug is talking about) the button to continue with the reauthorization.

If the request token isn't valid (the issue in this bug [T74654]), then we just don't show that button, or we give a message saying they should click "back" until they get back to the application doing the authorization.

That seems like it would be an overall better user experience, and also address Quim's bug about the scary sounding message when you re-authorize.

Event Timeline

bd808 created this task.Mar 6 2015, 7:19 PM
bd808 raised the priority of this task from to Low.
bd808 updated the task description. (Show Details)
bd808 added subscribers: bd808, csteipp.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 6 2015, 7:19 PM
Sitic added a subscriber: Sitic.EditedMar 28 2015, 9:01 PM

What's the point of having a "reauthorization" form if nothing about the consumer has changed (assuming valid request token and no revoked grants)? I wouldn't expect a user to click on "Login" on a tool in order to then revoke the authorization. If I wanted to revoke authorization for an app, the intuitive way for me would be to search for connected apps in the settings on my favorite wiki.

I would suggest to go straightaway to the callback and not show any form, it seems to me that many large oauth service providers do it this way.

Tgr added a subscriber: Tgr.Aug 16 2015, 9:20 PM

Just to make sure I am understanding this right: right now we keep access tokens forever (OAuth 1.0 allows but does not require an expiration time) so if an application does its own user management and records the access token it gets after the user clicks through the authorization dialog, that application can act in the name of the user forever without ever needing to reauthorize. The only thing a user-friendly reauthorization dialog affects is how much more complicated the workflow becomes for applications which do not keep track of the access tokens (or keep track in a non-permanent way such as a cookie) and just re-request them every time.

If that is a correct understanding of the situation, then Sitic's suggestion seems like a no-brainer to me. It would make writing small applications easier and would not have any security effect.

Right. Also, I came here to report a bug/request which would be, I guess, solved by this one: AFAICT, if I remove an optional permission to an application, but come back later and the application asks to reauthorize (reauthenticate, really), the permission is automatically re-added and there is no way to prevent it in the login dialog. I need to approve the application, which re-adds the permission and redirects me to the application, then manually go to Special:OAuthManageMyGrants and remove the permission again.

The dialog should either contain the checkboxes like Special:OAuthManageMyGrants does (pre-filled per the current grant), or it should not touch the currently allowed permissions at all, I’d say.

Tgr added a comment.Jul 4 2017, 3:41 PM

I don't think we should encourage people to revoke specific grants at random, that will just result in the application breaking and the developer having a hard time to debug. Personally I wouldn't allow piecewise revocation at all. You either trust the developer to know what they are doing or not, in which case you shouldn't authorize.
(Empowering the developer to make the grant more granular would be nice OTOH. That's T59505: Allow more flexibility in what permissions are authorized.)

In any case, there is no way to "un-revoke" grants right now other than going through authorization again, so if that did not reapply all grants, manually revoking the wrong grant would irreparably break the application for the given user.