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:

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:

Does it make sense to anyone?

I'm not a native English speaker and I'm trying to improve my language skills. Please feel free to use comments to correct any grammatical and spelling errors!

Comments: 5 (feed)

  1. Konstantine Rybnikov

    That's exactly my point -- it's too complex and general right now. But I disagree with "best practices" part. The simple thing that MUST be achieved is to add "log in via <top10 most popular websites>" to your portal in 30-40 minutes (+ your own business-logic). Right now, it's rather a horror (which is also not so easy to test by hands, and very hard to test automatically).

  2. egor homakov

    wdyt http://homakov.blogspot.com/2012/08/saferweb-oauth2a-or-lets-just-fix-it.html ?

  3. homakov

    also it's framework, nobody said it's protocol

    "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.

    oauth has nothing to do with logging in. although many apps use it for authentication too.

  4. oauth has nothing to do with logging in

    This is exactly my point. Since OAuth is too broad to be a protocol, I believe there should be a real protocol implementing a much more narrow and common use-case of logging in using OAuth. This protocol could apply identification semantics to tokens (becoming an authentication protocol) and specify an extensible way of getting profile data akin to what Attribute Exchange does for OpenID but in a sane way.

  5. homakov

    I am sure providers will not support 2 protocols at the same time only to keep authentication separately from authorization. Now it is quite simple and they all return 'uid' and some profile details - enough for authentication. but if client wants some private photo - authorization helps. thus oauth is good combination

Add comment

Text delimited with a blank line becomes paragraphs, quoting is done with > on the left, list consists of items with a minus on the left, italic is marked with * from both sides, bold -- with **, code blocks are indented with 4 spaces