Topic on Talk:OAuth/Flow

That response on OAuth 2 over https is misleading. OAuth 1 included reasonable levels of security even without https, OAuth 2 removed them because they thought the signatures were too complex (And as far as discoverability the OAuth 2 editor has some negative comments about signature removal).

If this is going to be a real MediaWiki feature rather than something practically Wikipedia only then what we're really going to have to aim for is an abstract interface which is extended by extensions implementing OAuth 2, OAuth 1, and perhaps some other form of auth not something written from the start to only support OAuth 2.

AFAIK, signatures are back since OAuth 2 draft 11, and we are know at draft 22.

I read back through OAuth 1, OAuth 2, and the OAuth 2 MAC token specs. Taking a look at it I've found that while signatures are back in a way. From a security standpoint they are completely inferior to the signatures used inside OAuth 1. They only protect the resource server (and don't even protect that entirely) and don't protect the authorization server. In effect while OAuth 2 has "signatures", they are practically useless. You still need to run HTTPS on your wiki to be able to use OAuth 2 securely.

On this topic I ran into this post: http://blog.astrumfutura.com/2010/10/do-cryptographic-signatures-beat-ssltls-in-oauth-2-0/

It's nice to hear that signatures are coming back (though I can't find them when scanning the spec). But I do have something important on this topic:

• The big issue with not having signatures is discoverability. No signatures + discoverability = phishing basically.
• While everyone talks about OAuth on Wikipedia, the frank reality is what we'll be developing is OAuth for MediaWiki. Which is a different beast that will inevitably end with lots of small MediaWiki installations installing OAuth.
• We're also already talking about anti-vandalism tools using OAuth. And quite frankly, while Huggle is WMF-centric OAuth is inevitably going to be used for other anti-spam tools, bots, etc... which of course may not be WMF-centric.
• This means that discoverability is inevitable. We will have OAuth on many MediaWiki installations and we will have clients that want to work with more than just WMF.
• This also means that wikis without HTTPS are inevitable. There are thousands of MediaWiki installations without it, plenty that will have users that want to use apps that will use OAuth, and plenty without a budget for a SSL certificate.

So under these circumstances I think we need the following:

• When we do implement OAuth, we include the signatures implementation right away.
• By default we DO NOT support OAuth without signatures. Only wikis that have explicitly enabled non-signature support will accept clients not using signatures.
• Even when signatureless OAuth is enabled we ALWAYS support signatures. If a client asks for authentication using signatures we ALWAYS respect that.
• We keep the situation where we have an arbitrary number of MW API clients using OAuth and an arbitrary number of MediaWiki instances supporting OAuth in mind and remember we'll eventually need to support the situation where a client can work with a MediaWiki installation without the author explicitly registering with every MediaWiki instance in existence to support them all.

I know that there's still some issue with OAuth over http even with signatures. But I believe that's something that can potentially be handled in the discoverability process. It's also still better than the alternative.