Two-legged OAuth - looking for information

Question

I want to implement a new REST-based API on our infrastructure, and OAuth seems to be the way to go.

For our implementation, there will first just be server-to-server access, which will be completely unrestricted. I believe this is called two-legged authorization.

Later on, we'd like to allow the API to be consumed by the browser, which will turn our authorization into three-legged.

Is there a good starting point for implementing this? How can we fully authorize a server and down the road add restricted authorization per-user?

The OAuth specification is not really helpful in these scenarios, but I believe this implies we need to create a never-expiring session for the server-to-server access, and later on add normal sessions with limited access for user-only APIs.

I'm hoping to find starting points for more information, let me know!

Is OAuth for me? I'm only looking for a authenticated request system, and only the consumer and service provider exist in this scenario. The end-user does not come in to play!

Chyou

Answer 1

OAuth will end up being too difficult for our needs. I've decided to adopt Amazon S3's authentication scheme, simply because it fits our model better.

Thanks for helping out finding an answer though..

Chyou

Answer 2

Ya, OAuth is probably for you.

There are actually two OAuth specifications, the 3-legged version and the 2-legged version. The 3-legged version is the one that gets most of the attention, and it's not the one you want to use.

The good news is that the 2-legged version does exactly what you want, it allows an application to grant access to another via either a shared secret key (very similar to Amazon's Web Service model, you will use the HMAC-SHA1 signing method) or via a public/private key system (use signing method: RSA-SHA1). The bad news, is that it's not nearly as well supported yet as the 3-legged version yet, so you may have to do a bit more work than you otherwise might have to right now.

Basically, 2-legged OAuth just specifies a way to "sign" (compute a hash over) several fields which include the current date, a random number called "nonce," and the parameters of your request. This makes it very hard to impersonate requests to your web service.

OAuth is slowly but surely becoming an accepted standard for this kind of thing -- you'll be best off in the long run if you embrace it because people can then leverage the various libraries available for doing that.

It's more elaborate than you would initially want to get into - but the good news is that a lot of people have spent a lot of time on it so you know you haven't forgotten anything. A great example is that very recently Twitter found a gap in the OAuth security which the community is currently working on closing. If you'd invented your own system, you're having to figure out all this stuff on your own.

Good luck!

Coridon

Great answer Chris. I don't suppose anyone has experience of a 2-legged provider in DotNetOpenAuth do they? – Wallen

Answer 3

Remember to distinguish between authentication and authorization. In some places, I believe that the OP mixes the two.

For example, once a server authenticates someone, it usually explicitly or implicitly (using cookies) provides an authentication token so that subsequent requests are already authorized.

It is up to the server how long the credentials last. It is smart to plan that the credentials will time-out at some point. Just have the client server be prepared to re-authenticate itself whenever it receives the "authorization expired" error response.

You don't want to try to provide a "never-expiring" session since:

1. Everything expires at some point. For example, how will the client server be able to start accessing the application again if it loses power or is rebooted?

2. You're creating an inflexible system. They tend to break more often.

3. Since you know that you want to add additional types of logins in the future, instead of two types of logins (server clients and browser clients), make just one type of login now. The additional work for the client server will be to implement a "re-login as necessary" capability.

Lashay

Hi Larry, A never expiring session is common practice, and does not mean we lose the session when the server reboots. Sessions are stored in multiple databases and memcached instances. With session, I mean a 'persistent token'. Facebook uses this for instance. – Chyou

Lastly, our current system uses an 'API KEY', which is insecure because it needs to be sent plain over the wire (HMAC-MD5 based on a few variabels would be better), and the api key should under no circumstances end up on an end-users machine. This is why I went to oauth. – Chyou