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

"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.

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:

In T124690#3773602, @fantasticfears wrote:

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.

In T125337#4845308, @Qgil wrote:

(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.

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.

In T125337#4849739, @Tgr wrote:

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?

In T125337#4849792, @Anomie wrote:

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).

In T125337#4850975, @Tgr wrote:

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.

I think there are some great best practices in https://aaronparecki.com/oauth-2-simplified/ .

I think that T221161 is related.

Hi, just a note to say that we may not need OAuth2.0 for the Discourse use case after all. See T215052: Add MediaWiki login support to Discourse, which is already being commissioned to a Discourse developer. @elappen-WMF is the project manager overseeing that work.

In T125337#5581462, @Tgr wrote:

Discourse uses OAuth 1.0 now.

The implementation of OAuth 2.0 should still be discussed. A fair share of the package/lib that implemented OAuth 1.0 were updated last almost half a decade ago, and almost major internet service provider have deprecated their support for OAuth 1.0. That means the entire ecosystem of OAuth 1.0 has kind of died out naturally. OAuth 2 is not a trendy new technology, but a fairly matured ecosystem. Such discussion could be beneficial.

The implementation of OAuth 2.0 should still be discussed.

@Viztor: It has already been discussed here, see the many previous comments and the included arguments. Feel free to reply to specific arguments (by quoting them) if there are any arguments which have not been brought up yet and that you would like to add to this conversation. Thanks a lot!

Hi, see T229500: Add OAuth 2.0 support to MediaWiki.

In T125337#5767057, @Qgil wrote:

Hi, see T229500: Add OAuth 2.0 support to MediaWiki.

Thanks. This is of great help.