Page MenuHomePhabricator

Add OAuth 2.0 support to MediaWiki
Open, LowPublic

Description

People would like to sign up with an existing Wikimedia account to https://discourse.wmflabs.org/ . Discourse ships with an Oauth2 plugin. Having OAuth2 support in MediaWiki would help in getting people sign up with an existing Wikimedia account to https://discourse.wmflabs.org/ . Developing an Oauth 1.0 plugin for Discourse isn't an alteranative says https://meta.discourse.org/t/does-anyone-have-an-oauth-1-0-plugin-sample/38779: "there is a reason everyone switched to 2.0".

Event Timeline

AdHuikeshoven updated the task description. (Show Details)
AdHuikeshoven raised the priority of this task from to Needs Triage.
AdHuikeshoven added a project: VPS-Projects.
AdHuikeshoven added subscribers: Tgr, jayvdb, Yair_rand and 3 others.
Tgr triaged this task as Low priority.Mar 7 2017, 3:48 AM
jayvdb updated the task description. (Show Details)Jun 1 2017, 6:23 AM
Ragesoss added a subscriber: Ragesoss.
revi added a subscriber: revi.Jan 8 2018, 6:04 PM

This would also obliviate the need for T120469 and allow us to make PAWS use of oauth secure.

Anomie added a subscriber: Anomie.Aug 19 2018, 12:41 AM

"there is a reason everyone switched to 2.0"

What is that reason, and what is the evidence "everyone" switched?

https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529 presents a counterargument to using OAuth 2.0.

Qgil added subscribers: CCicalese_WMF, bd808, JBennett, Qgil.

I am nobody to give an opinion about OAuth 2.0 vs 1.0. I just know that login to Discourse with a Wikimedia account would be useful in so many ways in the mid term. I also see Discourse supporting officially "social logins" for Facebook, GitHub, Google, Twitter and Yahoo + Single Sign-On with WordPress. In their forum there are reports of users implementing their logins for many other web services.

Also, the article posted by Anomie above says in a highlighted paragraph:

To be clear, OAuth 2.0 at the hand of a developer with deep understanding of web security will likely result is a secure implementation.

I would like to know whether there would be any blockers in developing an extension to provide Oauth 2.0 support for MediaWiki (or any alternative way to provide Wikimedia SUL to Discourse) and deploying it in Wikimedia's production servers. If lack of resources is the only problem today, then I would like to start a conversation with the affected teams at the Wikimedia Foundation to see whether we can pool the budget / time necessary in our next annual plan, including development, security review and deployment in production.

Just for context, currently we are providing the possibility to login to https://discourse-mediawiki.wmflabs.org/ via Wikimedia Phabricator. How this is done I don't know (neither how our Phabricator supports Wikimedia SUL).

Also, this might be interesting:

As far as I remember, Discourse has a PHP SSO example. It will be super easy to use. But it doesn’t have Unicode username support.

Anomie added a comment.Jan 2 2019, 4:57 PM

(neither how our Phabricator supports Wikimedia SUL).

I believe Phabricator uses the existing OAuth 1.0a to do its integration with MediaWiki. Chances are you'd be more quickly served by going that route, regardless of what one person at the now-dead link in the description had said.

Tgr added a comment.Jan 2 2019, 5:37 PM

Everything supports OAuth 2 (and usually only 2) these days, so in the long run we'd save time by adding OAuth 2 to MediaWiki instead of adding OAuth 1 to everything else.

OTOH our long-term plan for a movement-wide identity provider probably should not involve MediaWiki (or not the usual wikis, at least); as recent events have shown it's by far the least trustworthy identity verifier in our infrastructure, due to its leniency with user-editable Javascript. (This is not much of an issue for Discourse accounts which are typically not sensitive, but problematic for many other things.) But that's T140813: Protect sensitive user-related information with a UserData / auth / session service territory and probably even more distant.

A possible workaround would be to have some kind of OAuth2-to-OAuth1 gateway; AIUI OAuth 2 does not have signatures so it's OK for the client to not know that the request is going to be proxied somewhere else.

Anomie added a comment.Jan 2 2019, 5:47 PM

Everything supports OAuth 2 (and usually only 2) these days, so in the long run we'd save time by adding OAuth 2 to MediaWiki instead of adding OAuth 1 to everything else.

From what I've read, there's no way that anything can support OAuth 2 generically. Unless we slavishly copy Facebook's "profile" of OAuth 2, I doubt we'd actually have gained anything.

OTOH our long-term plan for a movement-wide identity provider probably should not involve MediaWiki (or not the usual wikis, at least); as recent events have shown it's by far the least trustworthy identity verifier in our infrastructure, due to its leniency with user-editable Javascript.

How do the recent issues with account compromise via misused user scripts in any way impact MediaWiki's ability to identify users? And how would having some other backend service serve to mitigate any of those issues?

Tgr added a comment.Jan 3 2019, 3:37 AM

From what I've read, there's no way that anything can support OAuth 2 generically.

Have a look at some actual OAuth2 client implementations. The vast majority of them just needs the three URLs for the handshake and some trivial parsing logic to handle the slight variations in the response format. That's no different for OAuth 1.

Unless we slavishly copy Facebook's "profile" of OAuth 2, I doubt we'd actually have gained anything.

We'd have gained out of the box support in a lot of frameworks which do not bother to implement OAuth 1.

That said, Discourse uses OmniAuth and OmniAuth does have a MediaWiki client, so adding support for MediaWiki's existing OAuth system should be trivial. For a typical site that's supported by OmniAuth the auth plugin is just a few dozen lines of declarative code.

How do the recent issues with account compromise via misused user scripts in any way impact MediaWiki's ability to identify users?

You can misuse user scripts to e.g. steal session cookies and use the stolen session to pass the OAuth check.
What I'm trying to say is, any service that relies on MediaWiki OAuth for identities can only be as safe against account compromise as MediaWiki is, and MediaWiki is not very safe (the way it's used for Wikimedia wikis, at least). Again, not a problem for Discourse specifically, but a big problem for SSO for developer tooling (Gerrit, Logstash, etc).

And how would having some other backend service serve to mitigate any of those issues?

By not letting you execute Javascript editable by random people. It would have to be a partially frontend service, of course (at least the login form would have to move over).

Anomie added a comment.Jan 3 2019, 3:58 PM

You can misuse user scripts to e.g. steal session cookies and use the stolen session to pass the OAuth check.

The session cookies are flagged as 'httpOnly', so JS shouldn't have access to them in the first place.

And how would having some other backend service serve to mitigate any of those issues?

By not letting you execute Javascript editable by random people. It would have to be a partially frontend service, of course (at least the login form would have to move over).

In other words, it wouldn't. You have to get into reimplementing a full stack there.