- For client access to a server, use basic auth over HTTPS
- For client/server to server access, use OAuth
Note - I'm genuinely interested what people think as I'm just finishing off a personal project using a RESTful interface and this is the approach I have used so far.
[Edited based on comment - and I should point out that I haven't implemented OAuth yet but I should really check out how it would work].
On the other hand, it makes it more difficult for developers to access your API; you can't just send requests over Curl, for instance.
[I have seen some discussions about adding explicit support for OAuth in curl]
We (developers) do love re-inventing wheels.
[CLIENT] Hash (HMAC-SHA1 or SHA256 preferably) the blob of data data (from Step #1) with your private key assigned to you by the system.
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA!
HMAC isn't a hash. It's not interchangeable with a hash. HMAC is a MAC. If you try to use a standard hash function to create a MAC, it will blow up in your face. This article is not good, in multiple ways; you should disregard it.
No. Getting the username and cracking the hash is the least of your concerns. The problem of just hashing the password and sending it over an unsecured channel is that you're vulnerable to replay attacks: the attacker doesn't need to crack it, just re-send the hash. Essentially, the hash becomes a plain-text password.
People still think OAuth is complicated. OAuth 1 was very complicated and caused untold issues for implementers who didn't use libraries and for those of us who maintained libraries who to this day tell us that our proven libraries implement things wrong.
OAuth 1.0 should not be used for any new applications. OAuth is dead long live OAuth(2).
OAuth 2 is essentially ready to be used, but unless you need to deal with token issuance and delegated access you don't even need that.
If all you need is an API token over SSL then use the Bearer Token spec is what most people call OAuth 2 and is just a single token in a http header or query string. It is incredibly easy to implement and you don't even need a library.
http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-16
More complex but if for some reason you don't want to use SSL or if you need to share url's similar to Amazons signed urls where you need to give some access to a resource such as an image or download use the Mac token, which is receiving serious security analysis now:
http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-0...
Both of them are still officially drafts, but are mainly receiving wording changes now. I'd say they are both ready for primetime.
