On Fri, 24 Aug 2012 14:14:30 -0700, Daniel Friesen
<daniel(a)nadir-seen-fire.com> wrote:
On Fri, 24 Aug 2012 11:24:46 -0700, Chris Steipp
<csteipp(a)wikimedia.org>
wrote:
On Fri, Aug 24, 2012 at 10:33 AM, Nabil Maynard
<nadreck(a)gmail.com>
wrote:
> On Fri, Aug 24, 2012 at 10:16 AM, Tyler Romeo <tylerromeo(a)gmail.com>
> wrote:
>> Not a good idea:
http://xkcd.com/927/
>> While OAuth has its problems, it's not a terrible protocol (or at
>> least v1
>> isn't).
Randall is right in general about standards proliferation for standards
sake.
But that's primarily about just writing a standard for other people to
use.
If there are issues with the old standard, there is no significant
advantage to use of the old spec (besides the case that it already
exists, etc...), and you are intending to actually use the standard
rather than just throw it out for people to use. Then that's really a
valid situation to write a new standard in.
- OAuth 1 had some important issues too. In particular the temporary
credentials and the limitations on the user experience caused by the
single flow.
- The flow limitations is probably a big one for us. And it is possible
to work around the issue by separating OAuth into two parts. But by
doing that you diverge from the spec and there isn't much more reason to
stick with that standard. And afaik the libraries for doing OAuth 1
don't support these alternative types of flows.
Seconded
-- I'd rather see contributions to making OAuth less painful
rather than invent Yet Another Standard.
I have to agree too. OAuth has problems, but it would allow several of
wmf's current integrations to be more secure overall, and that would
be a win for us. If Daniel is able to create a protocol that is as
secure, and easier for developers to use securely, then I will
definitely push to switch over. But until then, I'm still going to try
and get OAuth out.
Thanks. I already know what I have lying around in my head will
keep
OAuth 1 level security while making signatures easier to implement.
Although the fundamental idea in this area is auth should always be done
by a library/SDK anyways.
The stuff making my head spin actually isn't even any part of the basic
auth. It's not even discovery itself. The hardest thing to figure out is
what to do about making discovery and dynamic registration over HTTP
secure.
Which frankly is something that no protocol has anyways.
The only problem with writing out an actual standard for the rest of the
stuff is all my good hours are taken up by work. The leftovers wouldn't
be enough to get out a good enough quality standard and
reference/testing implementation.
I just spent two ENTIRE days in a trance with nothing but auth flows
spinning around in my head.
All I was able to get out in writing so far is this draft collection of
high-level auth flows to aim to support.
Rather than jumping to "get OAuth out" what
about first trying to get
the fundamental base pieces we need for all of these into core. ie:
Abstract authorizations and applications. Revocation pages. Attaching an
authorization/application to changes like revisions, logs, etc... and
tools to mass-revert by confidential application or multiple public
authorizations.
We'll need that stuff no matter what we implement. And it's going to
take awhile just to implement those things.
We can decide whether we want OAuth or something else when we finally
get to that point.
I'd also love to see MediaWiki support SAML
too, for our .edu/.gov
users.
Did these organizations need to use those SAML credentials directly for
API
things or is this just another method we want to support for logging in?
My
personal wishlist:
- Persona: Previously called BrowserID. It's come a LONG way in the
past
few months, and provides another fairly clean identity/authentication
system.
Mozilla is also interested in this. I don't think we can use it on wmf
sites, but if you're interested in working on it, I can probably get
you in touch with someone there. I think it would be a great feature.