OAuth is not a protocol

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.

Too much freedom

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:

• Endpoint URLs are neither fixed nor is there any discovery mechanism for them.
• Application registration is mentioned but doesn't have any properties upon which implementors could rely.
• At one point the client_secret wasn't required leaving client authorization basically undefined too.
• The authorization scope — both the set of permissions and their semantics — is completely service specific.
• There are several ways to define a scope for a client: either during registration of an application or during an authorization request.
• There are no guarantees about the rights implied by the access token: nothing prevents a service from limiting the authorization scope of a token based on meta data or, say, user's decision.

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.

Libraries

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.

Not a protocol?

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:

• "WebAuth": a set of guidelines with all the different authorization flows and security considerations defined by current OAuth spec,
• "OLogin": a protocol with concrete endpoints, common permissions and client identification intended for a use-case of "Login with Something" that seems to be one thing that many different APIs share.

Does it make sense to anyone?