Blowing up OAuth

We’re getting more and more into OAuth here. We’ve found that once you get over the hurdle of the weird terminology, it makes a lot of sense. Several people have commented, it’s just simplified Kerebos for the Web.

I know nothing about Kerebos, so I’ll take their word for it.

But the OAuth spec provides for a couple of things. The first part of it is a spec for bouncing back and forth between a couple of servers to authenticate a user and exhange a set of tokens and token secrets.

Then you get to the good part, which is branding an HTTP request with a signature hash. It rolls up all the good parts of the HTTP request, and is a nice hashing and validation scheme. Everyone in the room could come up with their own hashing scheme, but as you refined it, it would end up being pretty much what OAuth has.

That’s where the fun comes in. Because OAuth provides for two tokens in the hash — an access token and a consumer token — but doesn’t provide any definition around what those really are or what they look like, suddenly everyone puts on their “thinking outside the box hat”.

There are lots of good ideas of how to turn the OAuth spec on it’s side this way: set up a token cache, and just jam all kinds of existing identifiers in there to use as the access token. Or use an existing identifier as a kind of long-lived access token. Or use short-lived consumer keys. Or don’t pass an access token at all.

Lots of these are actually good ideas, but fortunately we kind of forced ourselves to not be creative,  and read the spec narrowly.

The major way we’re being creative is we are using the “2-legged” variant where the access token is empty. Also, we’re defining our consumer keys to be very, very broad entitlement grants, and perform an additional entitlement check on the request URI *after* OAuth validation has succeeded.

Also, we’re moving toward the “nAuth” spec that Twitter (I think) is moving toward, where the first N jumps in the spec are covered with a single login/access token request.

I guess I don’t have a point here. It’s just been interesting to see all the different variations and the creative spins people are putting on tokens and keys. I’ve been putting off looking at the 2.0 spec, but I’ve heard that spec addresses some of those scenarios.


Leave a comment

Filed under open standards

Leave a Reply

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

You are commenting using your 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 )

Google+ photo

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

Connecting to %s