authorization - Using OAuth for server-to-server authentication?

Question

I'm currently working to specify my company's new partner/public API, which will be a resource-oriented RESTful web service. The missing piece of the puzzle at the moment is authentication/authorization.

The requirements are:

1. Initially it must work for a server-to-server environment, e.g. a server application must be able to identify itself so that we know who is calling the API.
2. In future, we would like to allow it to impersonate user accounts, so as well as the server being identified it would have a token that represents a user account for a limited period of time.

OAuth seems to be ideal for (2) with the workflow of getting a token, redirecting to the website where the user enters their credentials to authorize it, and then using that token which identifies/authenticates both the application and the user.

However, from what I have read, I don't know if it is suitable for (1) - i.e. is there any way that OAuth can be used just to identify the calling application without having a valid user-specific token and thus not needing to be redirected to a web page for them to enter their credentials?

Answer 1

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.

The 2-legged version does exactly what you want initially, 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.

Getting both 2-legged and 3-legged to work simultaneously is kind of tricky right now -- but it is possible (Google has it working right now). http://code.google.com/apis/accounts/docs/OAuth.html