oAuth 2.0 / Eran Hammer's Resignation

[Steven WIllmott]

I guess this has been brewing for a while: http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/

There's a pretty extensive Hackernews thread too:

http://news.ycombinator.com/item?id=4294959

[Jesse Emery]

Yeah, I've been following this as well. Its quite disappointing, but it's hard to blame him. And if you read the spec version-by-version you can see the progression of the issues he raises.

[Steven WIllmott]

haven't been able to follow it as much as I wanted to. In the pure web space in the end there was always some kind of tyranny of the browser makers - which had downsides, but also the plus of some kind of convergence. The worrying thing would be if there ended up being no focal point for this in the API space.

 steve.

[Jesse Emery]

What do you mean by "focal point?" Do you mean that people won't use it? Cause I think from a practical standpoint, most developers will just end up mimicking the Facebook or Foursquare implementations, which, ironically, are much more "specific" than the specification. Unless someone really comes forward quickly with something better/clearer.

[steve]

I don't think that's really enough - Facebook can change its implementation (rightly so) whenever it likes or even do something totally different. It's defn a good starting point for people now - but the you'll suddenly be into version numbers of facebooks take in openauth. They might be fine with it but its very fragile.

There needs to be a forum / consensus / maintenance mechanism.

[Jesse Emery]

Fair enough, I was think if people followed their implementations "in their current state." It looks like from the Hacker News thread that there is some momentum to basically document the basic common use-case (get a code to a callback, get a bearer token that expires but can be renewed, etc) separately to encourage some interoperable adoption.

[Kevin Swiber]

Unfortunately, I'm very familiar with "death by consensus."  It's difficult to reach wide-audience adoption without a series of compromises.  In the end, you have to ask yourself if the Frankenstein monster you created is still a creature you can love.  In this case, for this person, it appears not.

I'm glad to learn some devs are talking about providing guidance for common use cases.  I think OAuth 2 is still a very viable option in this space.  Fortunately, the majority of developers will likely rely on public guidance and example implementations over actually reading the spec.  It takes a special kind of nerd (like myself and I'm sure many of you) to tackle a specification of a technology standard.  Everyone else relies on what we have to say about it, so offering quality guidance is extremely important for the masses.

I'm curious to see where this goes and if anyone attempts an OAuth spin-off.

--
Kevin Swiber

Projects: https://github.com/kevinswiber
Twitter: @kevinswiber

[Carlos Eberhardt]

Another post on the topic:
http://blogs.mnt.se/the-bitter-taste-of-good-intentions/

[MattM]

Followup post today:

http://hueniverse.com/2012/07/on-leaving-oauth/

I think it's inevitable that as the spec seeks to support more use cases and cover more ground, it's going to grow in complexity.  Still, one of the main points of the original rant was that OAuth 2.0 allows bad developers to create insecure implementations.  I don't think there's a spec or a technology out there that can withstand and incompetent technician holding the keys!

[mca]

hmm....

he's shaping this in terms of enterprise vs. the web. didn't expect that. 

mca

+1.859.757.1449
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me

[Steven WIllmott]

Although that might be problematic, in a way I think he is right - these are two different roles. In enterprise scenarios you typically have tight control or links to everybody involved in the process - so decisions can be made and consensus created. If you're going outside you're typically an organisation large enough to have the clout to implement whatever you offer. 

In the general web world neither of those apply - having multiple small variations of something is wasteful and dangerous. The later on the security point - I agree, incompetence can make anything unsafe. But a nailed down spec means people can build libraries for major languages, get wide re-use and keep tightening them over time - helping people who have less security skills get stuff right. Fragmentation means those libraries probably wont exist.

I'm not sure Enterprise v's Web is a comfortable way to frame it exactly - we have customers of both types, but certainly in enterprise scenarios some of the needs are different and some of the problems have different solutions.

[Jordan Reed]

Enterprise v. Web made some sense to me - as someone who does almost all his work in Enterprise.  Really I think it's more modern standards v. legacy (and enterprise is great at legacy).  Because enterprises already have ways of doing stuff and when adopting new standards they want to be able to shape it around what they already have in place.

His mention of SAML is a great example - my company has created two different ways using OAuth 1.0 to integrate with SAML.  One method (user-interactive) for when the Authorize Flow needs to leave our application to go to the identity provider which asserts back to us during the flow.  And another method (server-to-server) to just SAML assert to get the access tokens.  We would have LOVED for this to be in the OAuth 1.x specs, but it's not.

In the earlier drafts of the OAuth 2.0 spec they were clearly defining actual flows for handling OAuth+SAML - but by the end, it's all melted away into very generalized descriptions of "Extension Grants" which talk about how could be done  Not even how it MAY be done, or SHOULD or MUST, but just how it could.  Why?  Because Enterprise organizations were providing examples like, "We don't use SAML, we used Liberty Alliance, how does that work?"  Or "We use the Passmark Authentication widget, how does that work?"  And so the spec got abstracted and abstracted away.  Even just in SAML some of the contributors were pretty crazy.

But anyway - I think we'll see some of the leaders of the space (Facebook, LinkedIn, Twitter, etc) move forward with best practices around this whole thing.

..J

[Mike Schinkel]

Sounds like what we really need to is two split oAuth into "Web Auth" and "eAuth."  "Web Auth" could be a new initiative that should be a very small discrete spec that would be easily to fully implement so that if someone has a "Web Auth" client or provider it is by definition compatible with all the others (save any programming bugs.) Then eAuth could be an extension of oAuth 2.0 and have all the special cases that enterprise needs.  JMTCW.

-Mike

[Ed Anuff]

I'm wondering where we categorize the signatures issue in this enterprise vs. web characterization?  That seems to be one of the areas of contention.  Is the desire to eliminate signatures an enterprise requirement or a web requirement? I tend to feel its the latter.

[Mike Schinkel]

On Jul 30, 2012, at 5:35 PM, Ed Anuff wrote:
> I'm wondering where we categorize the signatures issue in this enterprise vs. web characterization? That seems to be one of the areas of contention. Is the desire to eliminate signatures an enterprise requirement or a web requirement? I tend to feel its the latter.

As one who only deal with web and not enterprise, signatures are a PITA in my experience. So yeah. :)

-Mike

[Jesse Emery]

By "web" you mean like "web companies auth" right? Cause any new non-Enterprise spec would need to include flows for mobile and non-browser apps...  

[Mike Schinkel]

On Jul 30, 2012, at 5:52 PM, Jesse Emery wrote:
> By "web" you mean like "web companies auth" right? Cause any new non-Enterprise spec would need to include flows for mobile and non-browser apps...

Absolutely. Our main use of oAuth 2.0 is via non-browser apps, but every client's oAuth 2.0 seems to be implemented differently. So when I read Eran's posts his criticisms of oAuth 2.0 really resonated with me even though I expected to disagree when I started reading the first post.

-Mike

[Steven WIllmott]

Yes, maybe this is what needs to happen. Potentially "Web Auth" is even a profile of "eAuth", but it should be one which 

has a forum of some kind which is the guardian of the spec and helps it evolve sensibly (again could be the same 

forum as eAuth). The key thing is that is discrete and precise enough so that a proliferation of libraries can result and 

implementations are compatible.

 steve.

On Jul 30, 2012, at 2:20 PM, Mike Schinkel wrote:

[Jesse Emery]

I think the web crowd, assuming they figured out the signing implementation (which was itself the subject of a lot of complaints), still hated using signatures because they couldn't just use their browser to look at a response. Bearer tokens, for all their other drawbacks, accomplish this. 

Having said that, I can see the enterprise crowd not wanting signatures either, or perhaps more to the point: they didn't want particular guidance on how or when to do signing. They would want to roll their own. The only thing the latest draft says, which is telling, is:

"The token may denote an identifier used to retrieve the authorization information, or self-contain the authorization information in a verifiable manner (i.e. a token string consisting of some data and a signature).  Additional authentication credentials, which are beyond the scope of this specification, may be required in order for the client to use a token."

Jesse

[Mike Schinkel]

On Jul 30, 2012, at 6:33 PM, Jesse Emery wrote:
> I think the web crowd, assuming they figured out the signing implementation (which was itself the subject of a lot of complaints), still hated using signatures because they couldn't just use their browser to look at a response. Bearer tokens, for all their other drawbacks, accomplish this.

I'd be one data point to confirm your assumption there.

On Jul 30, 2012, at 6:16 PM, Steven WIllmott wrote:
> Yes, maybe this is what needs to happen. Potentially "Web Auth" is even a profile of "eAuth", but it should be one which
> has a forum of some kind which is the guardian of the spec and helps it evolve sensibly (again could be the same
> forum as eAuth). The key thing is that is discrete and precise enough so that a proliferation of libraries can result and
> implementations are compatible.

One thing Eran said in a comment[1] on his first post was that he thought maybe the best approach is for someone or a group of someones to "just do it" on GitHub. I rather like that as a good potential solution.

-Mike

[1] http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/#comment-41994

[Jon Moore]

I think this "web" vs. "enterprise" dichotomy is a false one. Enterprises want their APIs to be easy to use, and web folks want them to be secure.

One of the biggest criticisms of the process that Eran had was the lack of decisions. It wasn't the fact that enterprises showed up and made OAuth 2.0 all "enterprisey", it was that they couldn't come to a consensus and hence abandoned a protocol to create a framework instead.

This *isn't* an IETF issue or an enterprise issue. It was a standardization issue--the community failed to build "rough consensus and working [ed: interoperable] code."

Jon
........
Jon Moore

[Mike Schinkel]

On Jul 30, 2012, at 7:21 PM, Jon Moore wrote:
> I think this "web" vs. "enterprise" dichotomy is a false one. Enterprises want their APIs to be easy to use, and web folks want them to be secure.
>
> One of the biggest criticisms of the process that Eran had was the lack of decisions. It wasn't the fact that enterprises showed up and made OAuth 2.0 all "enterprisey", it was that they couldn't come to a consensus and hence abandoned a protocol to create a framework instead.
>
> This *isn't* an IETF issue or an enterprise issue. It was a standardization issue--the community failed to build "rough consensus and working [ed: interoperable] code."

I don't think it's false.

From what I'm reading, the issue with Enterprise is they need lots of flexibility in what and how they implement legacy support, especially related to the many different auth schemes they may have in use.

On the web, we need just one spec that is simple to implement, that is secure and that just works.

Simply put, the enterprises needed a framework and the web needs a spec.

-Mike

[Ed Anuff]

On Mon, Jul 30, 2012 at 4:35 PM, Mike Schinkel <mi...@newclarity.net> wrote:

Simply put, the enterprises needed a framework and the web needs a spec.

This seems like a good insight.  Might it be that the web devs place a higher value on interop, or is that reading too much into it? My impression seems to be that seamless interop was sacrificed pretty early on by all parties.

[Jesse Emery]

I think this:

On Jul 30, 2012, at 4:35 PM, Mike Schinkel wrote:

Simply put, the enterprises needed a framework and the web needs a spec.

Hits the nail on the head. It's called "The OAuth 2.0 Authorization Framework"  and not "The OAuth 2.0 Authorization Specification" (or protocol) because it's not SPECific. It's not a "spec" at all and a lot of people we're wanting/expecting a spec. Then they go and read it with that expectation and they're like "uh.... so... what do I implement?" And short of "almost anything you want" there isn't really an answer.

[Steven WIllmott]

I think this is a good characterization - the enterprise / web "labels" might trouble some since as you pointed out - enterprises want their APIs to be easy to use as well. I think the distinction is really:

 - In what scenarios do you have latitude to ask your API users to write custom code (or are you connecting to custom code already there): this 

   implies a level of leverage or at least direct communication. [which often happens in enterprise scenarios]

 - In what scenarios do you not have this leverage. [which often happens in open web deployments.]

If you are hoping for wide adoption by people as yet unknown to you want the spec you hang your hat on to be as nailed down as possible because people will have seen it before, written libraries etc. 

[Steven WIllmott]

On Jul 30, 2012, at 4:03 PM, Mike Schinkel wrote:

One thing Eran said in a comment[1] on his first post was that he thought maybe the best approach is for someone or a group of someones to "just do it" on GitHub. I rather like that as a good potential solution.

I like this idea too - but I still think you need a "body" even if it's a bunch of people that meet over beer - because requirements change over time, security issues happen, different languages need implementations etc. So if there's no forum of somekind, there's no legitimacy.

Note: I'm not arguing that IETF isn't that body or how it should be formed (api-craft has the meeting over beer part down to a fine art though!), I'm just saying even if it's specced out on github in a JFDI sort of way, there needs to be some accountability / legitimacy.

-Mike

[1] http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/#comment-41994

[Ed Anuff]

I think the call to fork is a bit premature.  There is still activity in the IETF working group and it appears to continue to be moving along.  The suggestion of going to some form of pre-2.0 OAuth (1.5?) didn't make much sense to me.  Oauth 1.0 was never very attractive, except to it's drafters, largely due to signatures.  There seems to be some notion that Oauth 2 circa rev 20 was on the right track, and if you look at Aaron Parecki's great presentation at OSCON (http://aaronparecki.com/An_Introduction_to_OAuth_2), you see that it looks like most of the public web implementations are based on drafts circa rev 10.  The question I would pose to this group is, as a bunch of folks generally interested and having a lot of experience in API best practices, do we have any consensus and opinion to contribute, and then would suggest that those with time and interest get involved in the IETF process.

[Mike Schinkel]

Please don't shoot the messenger.  Here's a quote directly from Eran's post[1] (BOLDED CAPITALS mine):

All the hard fought compromises on the mailing list, in meetings, in special design committees, and in back channels resulted in a SPECIFICATION that fails to deliver its two main goals – security and interoperability. In fact, ONE OF THE COMPROMISES WAS TO RENAME IT FROM A PROTOCOL TO A FRAMEWORK, and another to add a disclaimer that warns that the specification is unlike to produce interoperable implementations.

-Mike

[1] http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/

[Mike Schinkel]

On Jul 30, 2012, at 7:48 PM, Ed Anuff wrote:

This seems like a good insight.  Might it be that the web devs place a higher value on interop, or is that reading too much into it? My impression seems to be that seamless interop was sacrificed pretty early on by all parties.

Yes. I'd like to see open-source client code that supports "Web Auth" and know that I can point it at any "Web Auth" provider and "have it just work."  Can't do that with oAuth 2.0.

On Jul 30, 2012, at 8:02 PM, Steven WIllmott wrote:

I like this idea too - but I still think you need a "body" even if it's a bunch of people that meet over beer - because requirements change over time, security issues happen, different languages need implementations etc. So if there's no forum of somekind, there's no legitimacy.

Agreed, but I think the idea is that it starts on GitHub, gets lots of traction because it solves a well-defined problem that is sorely needed, and *then* the standardization body gets ahold of it.  So success comes before standardization as vice-versa doesn't seem as likely.

On Jul 30, 2012, at 7:58 PM, Steven WIllmott wrote:

I think this is a good characterization - the enterprise / web "labels" might trouble some since as you pointed out - enterprises want their APIs to be easy to use as well. I think the distinction is really:

To be clear I hope what I said in attempt to interpret Eran wasn't read to mean "An enterprise solution needs to be difficult to use!"  Clearly no, that's orthogonal; it doesn't need to be prescriptive and it needs to be flexible, which by nature often makes it less easy-to-use.

More importantly, the web needs prescriptive and not flexible as well as easy-to-use but just as importantly it needs to be relatively easy to implement the *complete* spec, not just portions of.

 - In what scenarios do you have latitude to ask your API users to write custom code (or are you connecting to custom code already there): this 

   implies a level of leverage or at least direct communication. [which often happens in enterprise scenarios]

 - In what scenarios do you not have this leverage. [which often happens in open web deployments.]

If you are hoping for wide adoption by people as yet unknown to you want the spec you hang your hat on to be as nailed down as possible because people will have seen it before, written libraries etc. 

Exactly.

On Jul 30, 2012, at 8:21 PM, Ed Anuff wrote:

I think the call to fork is a bit premature. 

Maybe instead of a fork, a "web auth subset."

-Mike

[Rob Richards]

I don't understand why so many people were so alarmed at Eran's resignation. One person does not make a spec and same was true with OAuth 1.0. There really isn't any need for forks or new web auth (hopefully people are referring to authorization and not authentication here). OAuth 2 is still moving along strong and is perfectly suited for all types of uses. To some of the points on this thread, true interoperability yet keeping things simple is a pipe dream. Everyone has their own set of criteria and a simple protocol just can not meet them all. There is work going on for a discovery format for use with OAuth 2 which then would allow for more interoperability as clients would be able to determine what and how they need to interact. Forking, why? If you look at what Eran was advocating, it was OAuth with HMAC (ala OAuth 1.0 with a few minor changes). Just use 2 with the HMAC ext. OAuth 2 just ended up growing into a much bigger beast than he had imagined and taking much longer to shape. In the end it's a good thing because having numerous types of implementations talking the same language it's easier to focus on common data formats, harden and solve security issues as well as more connectivity across silos (i.e. Web -> Enterprise and vice versa rather than having to create bridges). It is much better than in the past where all these difference technologies popping up to solve the same issue and each doing it differently causing a great amount of fragmentation.

Rob

[Francois Lascelles]

Now that the dust has settled, I think it’s clear that OAuth 2.0 is moving forward. I agree with Rob, I don’t get why this was such a big deal. At worst, Eran’s drama suggests the OAuth spec team is dysfunctional but the spec itself serves its purpose just fine. What is needed is a handshake protocol to issue a token that is later used to consume an API and OAuth 2.0 provides a great basis for this.

OAuth 2.0 is focused on the handshake protocol and leaves other parts of an authentication process open to the implementer. This flexibility makes OAuth more relevant in the enterprise. I happen to be involved with implementing API access control in many enterprise settings today and although OAuth 2.0 is central to most of these implementations, enterprise architects are well aware that secure access control requires a lot more than a handshake protocol. As part of these implementations, OAuth is being combined with strong authentication, with multi-factor authentication, with enterprise SSO, etc. OAuth is also being combined with XACML, with SAML, and other standards.

We happen to be discussing OAuth on tomorrow’s tech talk. We want to hear why and how you are moving fwd with OAuth (or not). Join us Aug 7 9am PST at facebook.com/layer7.

-fl