Though this post is obviously triggered by the recent damnation of OAuth 2.0 by the (former) spec editor Eran Hammer, it's not directly related to it. These are my thoughts about the technical role of OAuth that I wanted to blog about a year ago but couldn't force myself to do it. But as of now, it seems surprisingly relevant!
My experience with OAuth comes from being a project manager of the OAuth server at Yandex where I took part in the design, closely watched the implementation (up to about draft 16 of the spec) and helped writing developer docs.
What always struck me as odd was the amount of details in the OAuth spec that are implementation dependent. Here are some from the top of my head that I still remember:
client_secretwasn't required leaving client authorization basically undefined too.
Leaving those vast undefined grounds actually does make sense because real-world APIs differ immensely and creating a single detailed consistent authorization framework covering all their use cases is at the least impractical, if not impossible.
All this means that it's impossible to devise such a thing as a "generic OAuth library" that could perform the complete authorization flow against an arbitrary API. As I understand it, current OAuth libraries provide service for encoding language-native data into GET requests and parsing JSON responses. The rest — designing all of the UI and setting up callback URLs — is still application specific. Actually those applications that talk to one particular API don't even need all that library code supporting different real-world flavors of OAuth and would do fine with plain HTTP and JSON libraries. The only thing that a dedicated OAuth library really buys them is the luxury of reading developer-oriented docs instead of a formal spec (which is no fun at all).
By the way, the very fact that so many different OAuths are still floating around in the wild is an indication that developers don't see the point of converging their code to match a single spec since most of said code will remain service-specific anyway.
The point of any Internet protocol is enabling interoperability between arbitrary parties without additional peer-to-peer agreements. Your HTTP client can (mostly) talk to any HTTP server on the Web without so much as even learning its name. Since it doesn't seem to be the case with OAuth, wouldn't it be better to treat it as a set of best practices instead of a protocol? An "architectural style" if you will…
And may be there should be really two different things:
Does it make sense to anyone?