On Sat, 28 Jul 2012 04:15:39 -0700, Daniel Friesen
<lists(a)nadir-seen-fire.com> wrote:
On Thu, 26 Jul 2012 16:37:16 -0700, Daniel Friesen
<lists(a)nadir-seen-fire.com> wrote:
On Thu, 26 Jul 2012 06:13:52 -0700, Diederik van
Liere
<dvanliere(a)gmail.com> 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]