lists at nadir-seen-fire
Jul 30, 2012, 5:04 AM
Post #7 of 7
(249 views)
Permalink
|
On Sat, 28 Jul 2012 04:15:39 -0700, Daniel Friesen
<lists [at] nadir-seen-fire> wrote:
> On Thu, 26 Jul 2012 16:37:16 -0700, Daniel Friesen
> <lists [at] nadir-seen-fire> wrote:
>
>> On Thu, 26 Jul 2012 06:13:52 -0700, Diederik van Liere
>> <dvanliere [at] gmail> wrote:
>>
>>> Hi all,
>>>
>>> The lead author of Oauth 2.0, Eran Hammer, has withdrawn his name from
>>> the
>>> OAuth 2 spec:
>>>
>>> http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/
>>>
>>> That's a very sad news, IMHO, and it probably means we really should
>>> reconsider what protocol we want to support Oauth 1.0 / Oauth 2.0 /
>>> SAML or
>>> something else if we want to allow interoperability with our sites.
>>>
>>> Best,
>>> Diederik
>>
>> I thought OAuth 2 would have stayed dominant for a little while longer.
>> But this just circles right back to something I've said from the start.
>> We need to implement the Application registration,
>> authorization/revocation handling, and spam tools in a completely
>> abstract way that allows any protocol to be plugged in using an
>> extension.
>> ie: Everything that lets you revoke an App and see what app is
>> responsible for an edit would be part of core. While the OAuth2 flow
>> would be part of an OAuth2 extension.
>>
>> This post actually feels almost like an invitation to re-read OAuth 1
>> (I read OAuth 2 in much more depth than OAuth 1). Look over all the
>> advantages of each and come up with some real flows. And write a new
>> protocol based of the best of each. Try to write a simple usable
>> standard based off of that. And then ship MediaWiki with it hoping
>> others will pick up on the same protocol.
>> This kind of pushes me to want to write it myself. Though given my
>> past, that won't go well unless I have people behind me supporting it.
>>
>>
>> Btw, before anyone decides to use some short-sighted argument in favor
>> of OAuth 2 let's be clear about this. OAuth 2 is a protocol designed
>> entirely for proprietary APIs like Facebook. We absolutely SHOULD NOT
>> treat our goal as just a (proprietary) API for people to access
>> Wikipedia. But aim for a protocol that would work cleanly for all
>> MediaWiki installations.
>>
>
> I went back and read through the final OAuth rfc. Saw some stuff I
> didn't like of course. And there were some valid reasons for trying to
> replace OAuth 1 (even though what they came up with was a failure).
>
> Anyone want me to go back through the specs and make a list of some of
> the things that are wrong with both specs?
>
I've back through the specs and went over most of the issues in both specs
and a little bit on top with things we'll need that don't exist anywhere:
https://www.mediawiki.org/wiki/OAuth/Issues
Btw here's a little tidbit about existing /implementations/ of OAuth 2:
To use the client_secret credentials OAuth 2 defines a way of using a HTTP
Authorization: header with "Basic" HTTP auth. And a way of including the
client_secret as a client_secret parameter inside of a POST body, while
strongly recommending that method not be used.
Surveying the documentation for Facebook, Google, and Meetup's OAuth 2
implementations the way they support client_secret is quite consistent.
They *all* violate the spec. The three of them exclusively make use of the
client_secret as URI query parameter. This was never valid in any draft of
OAuth 2. Not even old drafts these providers are supposed to have
implemented.
So not even is OAuth 2 problematic from a security perspective and defines
itself as non-interoperable framework rather than a protocol. Half the
major providers that say they support OAuth 2 actually aren't even
following the spec.
;) In other words, OAuth 2 is looking pretty worthless right about now.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
|
