There are three options:

• use an OAuth 1.0 plugin for Discourse. I haven't found any, so we would probably have to write it.
• use an OAuth 2.0 plugin - it's included, but we would have to add OAuth 2.0 support to MediaWiki (a good idea anyhow)
• use Discourse's standard SSO (basically implement a special page where Discourse will redirect users, and send them back with the email address in a signed query string parameter). Easy, but it would be better to maintain a single SSO mechanism (OAuth, already used for Phabricator) on MediaWiki instead of two different ones.

Hi @Tgr. Thanks for your analysis. The first option you mention is probably the way to go now. I have asked for a sample Oauth plugin at https://meta.discourse.org/t/does-anyone-have-an-oauth-plugin-sample/38779.

I took a look over this and none of the options available currently can be done without several days of engineering effort. As @Tgr mentioned above, oauth1 is unsupported by discourse, oauth2 is unsupported by mediawiki. Getting either of these implemented correctly is likely to be a good bit of work.

The easiest one is to implement discourse's SSO. That would basically mean writing a mediawiki extension and getting it deployed in production. I think it's doable but writing, reviewing, gettting security review, and deploying to the cluster will take a few days of effort. I can help out with review/deploy, but i doubt i can find the time to implement this. There may as well be some push-back to deploying such a single usage extension to wikimedia production, even if we limit it to a single wiki (meta?).

One alternative that removes possible political obstacles is to write a simple intermediary that implements discourse's SSO, *and* MW OAuth login...

took a further poke around, could probably hack up https://tools.wmflabs.org/oauth-hello-world/index.php?action=download to be an intermediary between oauth1 and discourse sso.

another potential blocker though is that we don't disclose email addresses over oauth1 from mediawiki. Additionally once you go SSO we also need to provide things such as if the user is an admin or a moderator via SSO rather than in the discourse interface. This isn't a blocker but something that would have to be thought about. This could likely be based on the user rights on wiki, which are provided over oauth. Note that discourse doesn't make a distinction about per-category moderators, its all or nothing.Handling per-category rights via sso would probably be a pain anyways.

Thanks for looking into this. I understand it is several days of work no matter which option is chosen. To get this feature some funding or sponsoring is necessary or someone higher up in the hierarchy to allocate resources c.q. prioritize this task amidst the plethora of other tasks. I flag this for later.

In T124691#1993035, @EBernhardson wrote:

another potential blocker though is that we don't disclose email addresses over oauth1 from mediawiki.

We do, you need to select Authentication only with access to real name and email address via Special:OAuth/identify, no API access. when registering the consumer.

What about using Phabricator OAuth server as a temporary workaround. It may be a bit of fiddle to authenticate via Phabricator via MediaWiki , but most people on the target mailing lists will have a Phab account by now.

I don't know how useful would this be, but it has "Discourse", "MediaWiki" and "SSO" in the title. ;)

https://meta.discourse.org/t/using-discourse-sso-with-mediawiki/69218

In T124691#3728867, @Qgil wrote:

I don't know how useful would this be, but it has "Discourse", "MediaWiki" and "SSO" in the title. ;)

It's the wrong direction (sets up MediaWiki to let people authenticate with their Discourse accounts).

Discourse seems to use OmniAuth for several auth plugins and this https://github.com/timwaters/omniauth-mediawiki plugin exists that purports to work with MediaWiki OAuth. Making a proper upstream patch for MediaWiki as an auth provider seems like the best way forward if Discourse is a serious contender for production deployment.

In T124691#2777284, @jayvdb wrote:

What about using Phabricator OAuth server as a temporary workaround. It may be a bit of fiddle to authenticate via Phabricator via MediaWiki , but most people on the target mailing lists will have a Phab account by now.

I created a Discourse Phabricator connector (https://github.com/bekicot/discourse-phabricator-connect) that probably useful for this migration. It utilises Phabricator's OAuth service to connect Phabricator users into Discourse.

It also possible to add MediaWiki link to the profile and I think will take half a day to add that.

What's stopping a user from linking someone else's profile then?

In T124691#3874324, @TerraCodes wrote:

What's stopping a user from linking someone else's profile then?

@TerraCodes It can't because it is connected automatically via OAuth Server. It works like Twitter Verified account. And the user cant manually assigns himself as verified.

In T124691#3874334, @yana_agun wrote:

In T124691#3874324, @TerraCodes wrote:

What's stopping a user from linking someone else's profile then?

@TerraCodes It can't because it connected automatically via OAuth Server. It works like Twitter Verified account. And the user cant manually assigns himself as verified.

Oh, I thought you were adding a field on the profile to put the phab profile link. Also that link gives a 404 for me.

In T124691#3874322, @yana_agun wrote:

I created a Discourse Phabricator connector (https://github.com/bekicot/discourse-phabricator-connect) that probably useful for this migration.

@yana_agun thank you very much for your contributions. We are discussing the possibility to use your plugin at https://discourse-mediawiki.wmflabs.org/t/enabling-social-login/71. Feel free to join. :)

@Qgil I'm joining the discussion now. Thanks for your consideration. And also, i have followed the discussion there.

I think we can call this done? MediaWiki integration would be nice but not a low-hanging fruit and with Github + Phabricator I think we have decent coverage. We should IMO disable password-based authentication (after an announcement + giving a couple weeks to current users to make sure they have the right email address set) as it's one more password to worry about and not really compatible with Cloud VPS privacy policies.

Local account creation has been removed, and documentation has been updated. Yay!

I agree that proper Wikimedia SUL support is an extra task. We can expect our core audience to have Phabricator accounts or going to use them anyway. Good enough for now.