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:
- 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.
- 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?
Yes, the lifetime of the token can be set not to expire until you say so. So, you'd (manually) complete the authentication and authorisation, and save the authorized token for later use.
(You can use any test client to help you complete that manual part, or while you're implementing the server yourself: use a so-called two-legged OAuth.)
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
Greg:
I have been working on an extension to the OAuth core that I think may answer you need. We wanted to write applications against our own API, but we felt it did not make much sense to not allow our own applications (As the service provider) to collect credentials directly from the user / consumer application - since we already would be considered a trusted party to ourselves.
The extension allows for 1st, 2nd, and of course 3rd party (traditional OAuth), while using the security of tokens and secrets, and signing, etc... that the Protocol provides.
Our beta documentation on the extension can be found here.
If it's only about server-to-server communication, I would consider using authorization based on API key - just like bit.ly or FriendFeed.
来源：https://stackoverflow.com/questions/776679/using-oauth-for-server-to-server-authentication