Utterances of a Zimboe

Programming the Internet.

OAuth a closed system?

with 4 comments

Hm. This was really a major surprise: [OAuth spec]

OAuth includes a Consumer Key and matching Consumer Secret that together authenticate the Consumer (as opposed to the User) to the Service Provider.

I.e., the service provider needs to know the consumer service in advance. Although the spec says

Consumer Secrets MAY be an empty string when no Consumer verification is needed.

the approach is clear.

So, what’s my issue? It’s simply that the Consumer Key kills spontaneous federation. For example, OAuth might get very handy with the opening of the social networks, but not all social networks can (and much less should!) be registered to each other; with these 93 services, it would require 8556 registrations. Furthermore, these registrations could slow the growth rate of new services as the users had to wait for the services to register with each other. And, while I wouldn’t like to sound too cynic, this allows services to completely deny federation with other, chosen services. (Read: ‘big services’ may easily cripple ‘small services’ by closing them off).

Please correct me, but it seems the OAuth board took a step backward from OpenID. I’m a huge fan of OpenID, and I’d like to see also the OAuth taking the bright path.

Even Google’s own protocol has a more friendly approach in this regard (see also x-google-token):

Decide whether or not to register your web application. Registered web applications have the advantage of being trusted by Google; the standard caveat displayed to users on the Google login page is omitted.

Vs. “you MAY not need to register your application.” (Emphasis not mine, although the quote somewhat adapted..) But, at least the Google doesn’t punch you to the nose for a welcome (and that’s really something.. :)

This was also interesting (from OAuth; my bolds):

Service Providers SHOULD NOT rely on the Consumer Secret as a method to verify the Consumer identity, unless the Consumer Secret is known to be inaccessible to anyone other than the Consumer and the Service Provider.

Well, is it secret or not.. So, you still need to do IP-based authorization? This also undermines the “allows the Service Provider to vary access levels”.

I hope that I’m wrong and someone corrects me. I really would like to have an open federation mechanism.

Tags: , ,


Written by Janne Savukoski

September 26, 2007 at 11:27 pm

Posted in Internet

4 Responses

Subscribe to comments with RSS.

  1. This is a very good observation, and an important one that we are aware of with OAuth. The issue is that Google, with its x-google-token, is primarily targetting web applications whereas OAuth, instead, is focused on web applications, desktop applications and internet devices like Chumbies or Nabaztags. This means that Consumer Keys are inherently insecure, since they must be embedded in these downloadable applications, and are therefore more likely to compromised than a web application’s keys.

    OAuth should also work in Javascript applications, where the key will be clearly available in source code.

    Will this created a “closed” or inhibited adoption path? Not necessarily. It simply means that it will be up to each Service Provider to determine how to provide and manage its Consumer keys, if it decides to use any.

    There is already work being done on OAuth Extensions to address this. I invite you to help out with this and contribute ideas to the automatic provisioning and best practices for dealing with Consumer Keys.

    Thanks for your thoughts on this!

    Chris Messina

    October 2, 2007 at 10:46 pm

  2. Great! That you’ve acknowledged this, that is. And actually I didn’t expect much less as there’s apparently some very reasonable people drafting the stuff.

    And yes, you made the issue more tolerable; though, I would still state it a little less aggressively. Or, separate the cases with web services and ‘end-user accessible’ software more clearly? Something to underline the openness a bit more..

    About keeping the secret secret, isn’t it a solved problem with asymmetric cryptography?

    I could of course discuss this with the whole community.

    ps. nabaztags rok, respect :)

    Janne Savukoski

    October 3, 2007 at 12:47 am

  3. Ah, well, securing the secret doesn’t really help much. This certainly needs some further thinking… :)

    Janne Savukoski

    October 3, 2007 at 12:52 am

  4. Ok, I guess this is unsolvable (even harder than ‘non-trivial’ :) as you can change the application logic. But, this means that we’re talking about an invalid use case and thus shouldn’t even be offered as it might lure some poor Service Provider to trust on the Consumer Secret too much. And if nothing else, at least it’s misleading.

    However, it’s 1:31AM and I’m not absolutely certain that my logic above is completely flawless. :)

    Janne Savukoski

    October 3, 2007 at 1:31 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: