OAuth vs. API key

[Jason Mott]

I've been looking into using OAuth as the way to secure and keep track
of the Social Actions API consumers. I am relatively new to OAuth and I
think from what I've read it is not something we'd want to use for the
Social Actions API.

OAuth, from what I've read, is useful only when you have end users who
need to give a third party applications access to data behind an API
without having to give away their user-name and password to the third
party. The Social Actions API doesn't have that scenario. That is, the
third partly applications in our scenario are not consumer delegates,
but rather the consumers themselves.

Thoughts anyone?

My suggestion would be to use an old fashion API key and tie it to a
specific referrer (site/page hosting the application). Sort of the way
Google analytics does, for example. This would allow the Social Actions
API to capture meaningful statistics regarding API consuming
applications, and provide a good enough layer of protection/tracking to
allow us to add JSONP support. While this solution doesn't close the
security flaws of JSONP, it allows us to deny access to any offending
application once we become aware of it.

Thought on this too?

--
Jason Mott
Worker-Owner
Software Engineer

Ronin Tech Collective, Inc.
167 Main St. Suite 103
Brattleboro, VT 05301
888.200.5074 x369
http://www.ronincollective.com

[Peter Deitz]

Hi Jason,

Thanks for writing up this issue. Either way, I look forward to being
able to provide rich analytics on the impact of specific applications. I
recall discussing that OAuth would be helpful for providing one user
access to both the Social Actions API and the Social Entrepreneur API.

Would the old fashion API key functionality that you envision permit one
key to be used on two (or more) APIs?

All the best,
Peter

Peter Deitz
Social Actions
Founder / Executive Director
http://www.socialactions.com

USA: 415-425-7482 | Canada: 514-824-3270 | Skype: peterdeitz

http://twitter.com/peterdeitz
http://www.linkedin.com/in/peterdeitz
http://my.socialactions.com/profile/PeterDeitz

[Jason Mott]

Peter Deitz wrote:
> I recall discussing that OAuth would be helpful for providing one user
> access to both the Social Actions API and the Social Entrepreneur API.
>
> Would the old fashion API key functionality that you envision permit one
> key to be used on two (or more) APIs?

Single sign on is not the purpose or function of OAuth. Rather, it's a
way for an end user (Human) to grant application A permission to access
his or her data from application B without giving application A his or
her username/password. But the human would still need to provide that
information to application B if they weren't already logged in.

OpenID would be closer to what you're suggesting, as it's purpose is
single sign on. However, even that scenario doesn't really match our
requirements because OpenID is a human based system (i.e. a human still
needs to authenticate with the OpenID provider).

And in both cases of OAuth and OpenID, the security provided is centered
around the idea that data is protected on a per user basis. We aren't
doing that. Our layer of protection is more around keeping track of who
is using the same set of data.


Theoretically, we could devise a system to allow SA-API and SE-API to
share API key data. But since an API key is easy enough to distribute
and use, I can't imagine single sign on between the two would be worth
the extra effort. Is there a particular reason why single sign on would
be important?

[Peter Deitz]

Hi Jason,

I can't think of other use cases for the single sign-on for other API
users. If the traditional API key approach has your vote, let's do that.
I'm hoping there are existing Ruby libraries / code that will assist us
in implementing this feature.

[Jason Mott]

It'll be pretty easy to do, I'm already underway implementing the API key.

One thought came though, and perhaps this was implied all along and I
just hadn't thought it through, but I don't think we should put the atom
and rss feeds behind an API key because then we'd cut out the general
public who just wants to subscribe to them via a feed reader. So I think
this only makes sense for the JSON (and JSONP) api. Was that your line
of thought already?

[Peter Deitz]

Hi Jason,

Yes, JSON and JSONP only. :-)

[Peter Deitz]

Hi Jason,

Another quick point --> We may want to auto insert a default and
temporary API key so that the existing apps don't get cut off the moment
this new feature goes live.

[Jason Mott]

I can make it so that in our first pass, if no key sent, it just allows
it through. That way, developers will be able to test their keys when
they have them, but for now still have their applications work without
them. This "partial roll-out" step is also needed since we're tying keys
to the host server's domain name, and we want to make sure that feature
is working before we fully lock the API behind a key.