I've found a few good articles but they seem to disagree with regard to how many layers of security are required. Looking at other popular APIs doesn't offer much clarity. Twilio uses basic auth + HTTPS, Twitter uses OAUTH, AWS uses HMAC.. WTF?<p>Specifically if I'm using HTTPS, can I get by with a simple secret key sent with each request? I'm trying to balance ease of use with security. I don't want to require the API user to sign the payload/query using their private key if I can avoid it.
GitHub uses basic auth + HTTPS, but recommends OAUTH so that users:<p>1. Don't have to give their password to third party services<p>2. Can limit what kind of access the third party has (public vs private repos, for example)<p>3. Can reject a specific app's access without affecting that of others
Here are a few of the articles I've found:<p><a href="http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/" rel="nofollow">http://www.thebuzzmedia.com/designing-a-secure-rest-api-with...</a>
Complete, easy to understand article that outlines the HMAC approach but suggests that things can be much simpler if HTTPS is employed.<p><a href="http://broadcast.oreilly.com/2009/12/principles-for-standardized-rest-authentication.html" rel="nofollow">http://broadcast.oreilly.com/2009/12/principles-for-standard...</a>
Claims that you should use HTTPS and sign your queries using a private key. This seems onerous for the API user.
i don't see any reason to 'sign' a request over HTTPS if you're going to implement authentication.<p>hmac / signing makes sense if you can't afford the overhead of SSL, and don't mind exposing the request to a man in the middle / eavesdropper.