Page MenuHomePhabricator

Provide "authenticate" endpoint for regular users
Open, MediumPublic

Description

MediaWiki currently provides only "authorize" endpoint, but this means that users have to confirm the application again and again. By providing "authenticate" endpoint, users could just "sign in" and get immediately redirected back, without having to confirm anything, if all permissions are still same, and user has not revoked the application.

See Twitter documentation for more information: https://dev.twitter.com/docs/api/1/get/oauth/authenticate


Version: unspecified
Severity: normal

Details

Reference
bz69232

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 3:42 AM
bzimport set Reference to bz69232.
bzimport added a subscriber: Unknown Object (MLST).
Mitar created this task.Aug 7 2014, 12:05 PM
Mitar added a comment.Aug 8 2014, 10:01 AM

Is anyone from OAuth extension at Wikimania 2014? I am here, we could discuss this in person here.

I think Brad and Aaron are both there. I'm not.

I forgot to comment on this one, but I'm solidly maybe on this. Silent redirects make me a little nervous since they've been used, along with other vulnerabilities, to silently exploit the other vulnerability. Requiring a user click makes another vulnerability much harder to exploit.. but I can definitely see the use in several scenarios.

At the least, I've been thinking about setting up an alternate endpoint for Consumers that are only meant for login, and the text would say something more like "Login to XXX" instead of asking for authorization.

(In reply to Chris Steipp from comment #2)

I forgot to comment on this one, but I'm solidly maybe on this. Silent
redirects make me a little nervous since they've been used, along with other
vulnerabilities, to silently exploit the other vulnerability. Requiring a
user click makes another vulnerability much harder to exploit.. but I can
definitely see the use in several scenarios.

The use of this in conjunction with other vulnerabilities doesn't make it inherently dangerous. When oauth is only being used for login to a connected application I don't see where the danger lies. When the oauth authorization includes some elevated privileges then I can see the worry, however, couldn't the authenticate endpoint provide a session without any access beyond the granting of a login?

The reason I ask is because we are using oauth for phabricator login and it's really not at all convenient or user friendly to ask for authorization each time.

b5bedd8 added the endpoint, but only for authonly/authonlyprivate grants. It would be a trivial change to relax that. Given that @csteipp was ambivalent on this, it should probably be your call, @dpatrick.

Tgr added a comment.Oct 7 2016, 12:35 AM

See also T91801: Support a more user friendly "re-authentication" flow for returning users which proposes a slightly more cautious approach: do require users to click through again but make the dialog simpler and make it mention they already authorized this consumer in the past.

This seems like a good idea to me... If I need to make changes in phabricator to use the new endpoint then I'd gladly do so.

Perhaps the automatic redirect could be validated against a URL whitelist in order to reduce the possibility for abuse...

Mitar added a comment.May 2 2017, 8:21 PM

I still don't understand what abuses are here? I mean, the rest f the world uses OAuth with "authentication". Why they do not have to worry about this type of abuse, or what is a difference in trade-offs and threat models?

I think it would be really great if Wikimedia OAuth could be equally used as other OAuths. A really global and trusted OAuth service to compete with closed ones like Facebook and Google.

Can you explain how precisely would the attack work? To my understanding of OAuth, attacker cannot just redirect to "authenticate" endpoint to get the user to be logged in. They have to have app key as well. And the main way they can have that is if they are running inside the app's JS namespace. But if they run there (and can continue running after redirect back) then we have bigger issues anyway and the can effectively do whatever the app can do anyway. And if the app is used to use OAuth, then users are used to click through anyway. So attacker can just go through dialog to authenticate the user.

I think it is really dangerous to believe that just because we show a dialog that protects users. Users become habituated to such dialogs. In fact they might become less secure if we are popping them all the time and not just when something is different (app wants to ask for more permissions than last time, app tries to redirect to a different callback location prefix).

I would propose that we have "authentication" endpoint, and then we prompt only if permissions or callback location prefix changes, or if for example 120 days passed from last prompt. If everything is the same, then we do not prompt the user. By requiring that callback prefix is the same (minus query strings) we can really limit any abuses only to apps themselves, or anything which hacked apps themselves, which is then more or less then already problematic.

Tgr added a comment.May 4 2017, 12:47 PM

This seems like a good idea to me... If I need to make changes in phabricator to use the new endpoint then I'd gladly do so.

Phabricator probably uses the authonly grant, so just replace authorize with authenticate in the URL and it should work.

I think it is really dangerous to believe that just because we show a dialog that protects users. Users become habituated to such dialogs. In fact they might become less secure if we are popping them all the time and not just when something is different (app wants to ask for more permissions than last time, app tries to redirect to a different callback location prefix).

Agreed.

I would propose that we have "authentication" endpoint, and then we prompt only if permissions or callback location prefix changes, or if for example 120 days passed from last prompt. If everything is the same, then we do not prompt the user. By requiring that callback prefix is the same (minus query strings) we can really limit any abuses only to apps themselves, or anything which hacked apps themselves, which is then more or less then already problematic.

I like this proposal, I think this would address the concerns raised by @csteipp.

Tgr added a comment.May 8 2017, 6:01 PM

Eww. That would mean we have to keep track of when the consumer was last used, which would mean DB writes on all API requests. It wouldn't have much security impact either, gaining access to users who did use the service in the last 120 days is still plenty. (IMO the popups don't have much security impact in the first place; it is not hard to social engineer someone into re-authorizing a service that they did authorize in the past.)

Mitar added a comment.May 8 2017, 6:05 PM

You do not have to update database on all API requests, only on calls to authenticate and related OAuth calls (or are you calling OAuth calls API requests)? In any way, I do not mind having no expiration time, this is just if somebody really wants some dialogs. I am for less of them anyway. :-)

Also, this can be implemented more efficiently. When you issue a token you remember when you did that. And you revoke it after 120 days, which then prompts the dialog to get it anyway.

Tgr added a comment.May 8 2017, 9:04 PM

You do not have to update database on all API requests, only on calls to authenticate and related OAuth calls (or are you calling OAuth calls API requests)?

Oh OK, you said last prompt, not last time using that consumer to authenticate an API request. That wouldn't be too bad.
I would still prefer just getting rid of manual reauthentications though.

Also, this can be implemented more efficiently. When you issue a token you remember when you did that. And you revoke it after 120 days, which then prompts the dialog to get it anyway.

That would limit how long the OAuth application can act in your name. We currently don't have a time limit for that. I don't know if adding one would be desirable (although all the OAuth apps I can think of are interactive and so wouldn't be affected).

Mitar added a comment.May 8 2017, 10:01 PM

I would still prefer just getting rid of manual reauthentications though.

I would agree. Until there are a change in permissions asked or something. But, because maybe not everyone agree with that I am pointing out that there are also some middle points we can do between showing dialog every time and occasionally.

We currently don't have a time limit for that.

Hm, all API providers I know about (Facebook, Twitter) do expire their OAuth tokens at some point (you even get expiration time).

But I do not really care about that. We can also have unlimited time. Or very long time.