On Fri, 24 Aug 2012 14:14:30 -0700, Daniel Friesen daniel@nadir-seen-fire.com wrote:
On Fri, 24 Aug 2012 11:24:46 -0700, Chris Steipp csteipp@wikimedia.org wrote:
On Fri, Aug 24, 2012 at 10:33 AM, Nabil Maynard nadreck@gmail.com wrote:
On Fri, Aug 24, 2012 at 10:16 AM, Tyler Romeo tylerromeo@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. https://github.com/dantman/protoauth-spec/blob/master/auth-flows.md
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.