lists at nadir-seen-fire
Jul 30, 2012, 5:04 AM
Post #7 of 7
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
>>> OAuth 2 spec:
>>> 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.
>> 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
>> 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:
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
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